On 6/8/06, Gregory Maxwell gmaxwell@gmail.com wrote:
I have some questions from a technical perspective.
Before I answer these, let me ask if you agree with this being a reasonable idea in general. If it is, then for me it means that technical details should be worked out by technical people as the project moves along. Kennisnet actually told us that the proposal was more technically detailed than it needs to be in order to be funded.
- What is the purpose of the XML-RPC subsystem? Since the images
are fetched via HTTP in any case, why not simply perform the existence test via simple HTTP as well. If that were done no modifications would be needed on the commons side.
There are future queries where the subsystem would come in handy, such as: show me the available, pre-rendered thumbnails, a list of conversion services, etc. Some of these are mentioned in the specs.
- It would appear from the specification that their is no facility
for caching failures.
Sure, the system should cache non-existence, but given that we anticipate fairly low usage to begin with, and given that the process of adding and reviewing an image is interactive, I do not anticipate any major load resulting from putting that feature into a future version of MW even without such caching. MW has several caching mechanisms that would kick in anyway for pages that have already been viewed before. If it does cause problems, we can deactivate the Commons service entirely until the feature is improved.
- The proposed method of interwiki transclusion doesn't appear fully
formed enough to determine if it will be sufficiently strong to prevent instant commons from accidentally becoming an automated system for license violations. In particular there doesn't appear to be any strong assurance that attribution and license data will *always* be available when the image is available.
We don't have the same assurance for Commons usage within the Wikimedia projects either, I think.
- Although copyright concerns are mentioned, they don't seem to be
explored in depth. Commons has a huge amount of copyright violations on it today.
Then they should be deleted. InstantCommons is a manual, user-initiated process. Commons has no legal responsibility to stop users of other wikis from copying images from Commons, whether it is by means of manually downloading or uploading, or by setting their wiki up for IC and initiating an IC transfer process. The copyright cleanup script is a convenient thing we can provide, and by no means a legal necessity.
- If the remote wiki will download the full image in all cases, what
is the purpose of burdening commons with the additional transfer and storage costs of their thumbnail generation? Yes, if that size has been used before commons will have it... but it's quite likely that other wikis will use a large number of sizes which are not used on Wikimedia sites, and even if the best case they still cost us additional bandwidth. The far side will still need to perform thumbnailing for the image page for large images in any case.
It's a service which we can choose to provide - for some wikis, for some file formats, etc. This is a policy choice for Wikimedia to make.
- How will this address SVGs which are widely used on commons, but
not supported by mediawiki out of the box? Our support for SVGs requires a modifyed version of librsvg in order to operate securely.
The first iteration of IC could support SVG the same way it is supported today: If your local wiki doesn't have a backend rendering library, you can still upload them (locally or through IC), but you can't view them as rendered PNGs and scaled thumbnails. Future iterations could support SVGs through some XML-RPC based query/response mechanism for the PNGs, if Wikimedia wants to provide that service.
There are also some more complex issues, like where the $5,000 EUR fee comes from for what is, overall, such a simple feature set. But I don't want to create a flood of comments initially.
The feature set is reasonably simple. Do keep in mind that for a feature to be developed and for it to be "Brion-ready" generally takes some more time spent with testing, debugging, security review, etc. The developer is ready to use any surplus time for the purpose of developing Wikipedia content in one of the native languages of Ghana; Kennisnet was happy with that. Also keep in mind that this is his first MediaWiki project, so he'll need some tutoring from a skilled developer, which should be paid for.
Erik