[Foundation-l] Instant Commons : INCORRECT

Thu Jun 8 14:42:39 UTC 2006

On 6/8/06, Gregory Maxwell <gmaxwell at 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.

> 1. 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.

> 2. 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.

> 3. 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.

> 4. 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.

> 5. 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.

> 6. 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