In 1.5 (assuming there are no objections), image width, height and bit depth will be available in the image table of the database. This is mainly for scalability. It allows replication and read load distribution of this commonly requested data to be handled by the database, where we already have tools for such things. A simple future extension would be to bundle metadata queries for all images to be displayed on a page into a single query. This is only a few lines away now, but was not possible with the original NFS-based system.
Thumbnails are still not handled in a way suitable for our scalability goals, this will be my next task.
The code is in CVS.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling schrieb:
In 1.5 (assuming there are no objections), image width, height and bit depth will be available in the image table of the database. This is mainly for scalability. It allows replication and read load distribution of this commonly requested data to be handled by the database, where we already have tools for such things. A simple future extension would be to bundle metadata queries for all images to be displayed on a page into a single query. This is only a few lines away now, but was not possible with the original NFS-based system.
Nice! While you're at it, would it make sense to include a field for the media type (not the file type) as well? Like, "image", "audio", "video", coded as integer values.
That would make (interface to-be-written) searches for media easier on the database, compared to
... WHERE img_name LIKE "%.jpg" OR img_name LIKE "%.jpeg" OR img_name LIKE "%.png" OR img_name LIKE "%.gif" OR img_name LIKE "%.tif"
Magnus
On Apr 11, 2005 8:22 AM, Magnus Manske magnus.manske@web.de wrote:
Nice! While you're at it, would it make sense to include a field for the media type (not the file type) as well? Like, "image", "audio", "video", coded as integer values.
If there was (eventually) a way for users to change this on upload and/or from the description page, this could also solve (or assuage) the irritating ambiguity of ".ogg" (Ogg being able to contain audio *or* video, though ".ogg" normally represents Ogg Vorbis because that "got there first").
Having that info to hand in an instant would also be great for having proper "display" support for media other than images, too.
On Apr 11, 2005 7:22 PM, Daniel Wunsch the.gray@gmx.net wrote:
On Monday 11 April 2005 09:22, Magnus Manske wrote:
Nice! While you're at it, would it make sense to include a field for the media type (not the file type) as well? Like, "image", "audio", "video", coded as integer values.
mimetypes?
Well, the first half thereof: "media type (not the file type)" :p. I'm guessing Magnus was thinking ints would take up less space, and be easier to manipulate (since the aim was to avoid text-matching queries)?
wikitech-l@lists.wikimedia.org