Hi,
After playing around with several ideas, and looking at the source of
gmediaserver and renderer I'm not so sure anymore whether writing a
generic gupnp-av framework would make sense. Implementing any AV
component using the API provided by gupnp is easy, and by further
abstracting the actions and events available we'd end up forcing a
certain, in many cases undesirable, structure upon API users.
For example, by providing a friendlier ContentDirectory.Browse API we'd
end up forcing either a browsing structure based on the structure as
served up by the ContentDirectory itself (the filesystem hierarchy in
many cases), or one on the basis of (possibly incomplete) metadata,
neither of which is obviously preferable to the exclusion of the other.
In many cases it will be desirable to directly control the Browse action
so as to be able to parse, in appropriately sized chunks, the data into
an app-specific data structure.
What might, on the other hand, be useful is to have a system D-Bus
service listing the available MediaServers and their tagged content as
well as available MediaRenderers. It wouldn't abstract things a terrible
lot though and may therefore be mere bus clutter. A system D-Bus service
providing an active MediaServer device would not make sense because
different users may want to export their media collections
simultaneously under different names ("$USER's collection"), though on
the session bus it may be useful.
What do people think?
Thanks,
Jorn
On Wed, 2007-07-25 at 18:28 +0300, Zeeshan Ali wrote:
> Hey Jorn!
> After the release, i guess you'll be getting onto the wraper libs
> and may i guess that the first one would be gupnp-av ? :) If that is
> true, can you share with me any design docs you might have and take my
> feedback on it before actually implementing them? :)
>
-- To unsubscribe send a mail to gupnp+unsubscribe\@o-hand.comReceived on Mon, 06 Aug 2007 13:10:20 +0300
This archive was generated by hypermail 2.1.8 : Mon Aug 06 2007 - 07:00:13 EDT