Re: Consolidating Core Desktop libraries

["Zeeshan Ali (Khattak)" <zeenix gmail com>]

On Mon, Nov 22, 2010 at 11:38 PM, Ivan Frade <ivan frade gmail com> wrote:
> Hi
>
> On Sun, Nov 14, 2010 at 4:21 PM, Zeeshan Ali <zeenix gmail com> wrote:
>>
>> > > One could also think
>>
>> > > about reanimating the once proposed d-bus-based thumbnailer[1] if more
>> > > users show up.
>>
>> Rygel also needs this. Currently we just serve the thumbails if they've
>> been already created by another app but its very much desired to be able to
>> create them ourselves or request another entity to do that.
>>
>> > > [1]: http://live.gnome.org/ThumbnailerSpec
>> >
>> > That spec is over-engineered, and far too complicated for what we want
>> > to use it for.
>>
>> True and one reason I'm not using it already in Rygel. Another reason to
>> not use this spec is that IMHO we should have one service for both thumbnail
>> and albumart extraction/download with simple APIs (get the
>> thumbnail/albumart for this URI/album/artist and notify me when its done).
>
> Maybe the spec is too verbose, but the API itself is simple for application
> developers: a "Queue" method to request the thumbnail,

  Just as an example there is a 'mime_types' parameter to that method
which IMO doesn't make any sense. To complicate the matters more,
there is ways to 'register' specialized thumbnailers. We need
thumbnails for pictures and videos, both of which can be handled by
gstreamer in a dynamic way by a single thumbnailer.  On top of that,
there is more parameters of this "simple" Queue method (flavor and
scheduler) that really doesn't need to be exposed to application
developer.

> Album art is a different issue, and you depend there on external providers.

  That does't mean we can't have the same service (application) handling both.

> Not that is not possible, but requires a second thought.

  Sure, what doesn't? :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124