On Thu, 3 Feb 2011 13:35:06 +0100 Jannis Pohlmann <[email protected]> wrote:
> On Thu, 03 Feb 2011 14:11:20 +0200 > Marius Vollmer <[email protected]> wrote: > > > But when an application requests a thumbnail from Tumbler, it either > > needs to be able to control whether Tumbler creates a PNG or JPEG, > > or it needs to be able to find either the PNG or JPEG, depending on > > what Tumbler has decided to generate. (And it needs to be able to > > find an existing thumbnail without talking to Tumbler, so it really > > needs to check for both; Tumbler can't just report what it has > > generated.) > > Since only one cache backend can be active at a time, I guess the > Thumbnailer1 or Cache1 interface could have a method > GetThumbnailFormat() that returns a format string for the > thumbnail location and a thumbnail MIME type for the image format > being used: > > So, for the default cache backend based on the thumbnail managing > standard, this would be: > > Thumbnail location: /home/username/.thumbnails/%f > Thumbnail MIME type: image/png > > For the JPEG backend it would be: > > Thumbnail location: /home/username/.thumbnails/%f > Thumbnail MIME type: image/jpeg > > The %f would stand for the flavor string (e.g. "normal", "large", > "cropped"... whatever). Applications could use this string to build > the thumbnail paths when looking them up. Please note that applications don't need the thumbnail meta data at all. They simply request thumbnails when they need them and tumbler handles the meta data checks and saving internally. So all that apps need for loading thumbnails is the base path and information from which they can deduce the thumbnail file type/extension (assuming that all backends use "md5(uri).extension(mime-type)" as the thumbnail basename). What do you think about this idea? - Jannis _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
