On Mon, 18 May 2009 16:01:27 +0200 Jannis Pohlmann <[email protected]> wrote:
> On Mon, 18 May 2009 13:48:08 +0200 > Philip Van Hoof <[email protected]> wrote: > > > On Fri, 2009-05-15 at 04:00 +0200, Jannis Pohlmann wrote: > > > > > In theory, this should completely hide how thumbnails are stored. > > > For instance, it doesn't really matter whether a cache is used or > > > not. It doesn't even matter where the thumbnails are stored. > > > > That is correct, except of course that a consumer will need to know > > about the thumbnail-spec (the storage one) to know where he can find > > the thumbnails when they are ready. Or where he can find the > > failures. > > > > It's however the case that for our use-case (Nokia's devices) we are > > only interested in cropped, not large nor normal, and that we want > > to store thumbnails as JPeg files, not PNG. > > > > So we believe that the storage specification for thumbnails isn't > > complete or rather isn't flexible enough. > > Possibly. One part of the thumbnail spec I'm not exactly happy with is > that failed thumbnails are stored per application. This means that > e.g. for G_FILE_ATTRIBUTE_THUMBNAIL_FAILED, GIO has to use hard-coded > fail paths (right now it only checks fail/gnome-thumbnail-factory/). > > > > Of course this raises the question how the interfaces should be > > > named. Should it be org.freedesktop.thumbnailer.* or > > > org.freedesktop.thumbnails.*, or even a mixture of both? Should it > > > be org.freedesktop.thumbnailer.Cache or .CacheManager? > > > Also, the name .Generic is rather undescriptive. I'm pretty sure > > > we there's a better name for this. Let me > > > throw .Provider, .Service or .Delegate in the pot as a few of my > > > first ideas. > > > > > > How about : > > > > org.freedesktop.thumbnails.Thumbnailer > > - Queue > > - Unqueue > > - Ready > > - Error signal > > - Finished signal > > - Started signal > > Having everything under org.freedesktop.thumbnails makes me wonder > what to do about org.freedesktop.thumbnailer.Thumbnailer which is > used for specialized thumbnailers. I guess it would be better to move > them all into the same namespace and name them differently (not using > Thumbnailer twice). Thoughts? > > > org.freedesktop.thumbnails.Cache > > - Move > > - Copy > > - Cleanup > > As a consequence of the above I'm wondering about a new method called > Failed(). But even that doesn't really solve the problem of where the > failed thumbnails are stored of course. > > > org.freedesktop.thumbnails.Manager > > - Register > > - GetSupported > > I'm thinking about the situation where manager and generic thumbnailer > are implemented as separate daemons. In that case we'd probably want > additional methods like this one: > > - GetThumbnailers (returning the D-Bus names of all registered > specialized thumbnailers). > > And maybe a signal > > - Registered() (including the D-Bus name of a newly registered > specialized thumbnailer). Ideas for an additional method: - Unregister (to explicitely unregister the D-Bus name of a thumbnailer). At the moment implementations of the manager interface have to listen to the "destroy" signal of proxies created for dynamically registered thumbnailers. This is more of an implicit unregister which I don't think is nice. That would also lead to another signal: - Unregistered (sent when the D-Bus name of a thumbnailer is unregistered using Manager.Unregister()). Based on that, clients of the generic thumbnailer/manager services could cache the supported MIME types and listen for Registered and Unregistered signals to update this cache. Cheers, Jannis
signature.asc
Description: PGP signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
