[vlc-devel] core playlist

[Jakob Leben]

On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <pdherbemont at gmail.com>wrote:

> Why can't the client just listen to the event?
>

Because that implies that the module should discover automatically all the
top level items, their children, their children's children, their children's
children's children... Would you like that in case of shoutcast for example?
Huge waste of time. Discovering items shall be done only upon clients
request.

Currently SD discovers automatically only the top level items, so it is not
a big deal, while further children are discovered upon request by "playlist
demuxers". It is only a matter of consistency, to actually discover also the
top items only on request.


On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <pdherbemont at gmail.com>wrote:

> I'd like it better if this was addressed at the SD level, ie - the SD
> ensure that it does always produce the same services_discovery_item_t for a
> children, not the client. If that's impossible fine.
>

You mean that the SD should always return exactly the same pointers? Than
that implies it has to permanently store discovered items somewhere. That is
one thing I wanted to avoid. I wouldn't force any prerequisites on SD
modules regarding what information they have to store.

I would actually prefer the services_discovery_items to be allocated only
statically and copy-returned (like Qt4's QModelIndex), but then I thought 2
things: maybe it's a waste of processing that data in an item has to be
copied every time + it is then left to be a responsibility of the module
that it doesn't store huge amount of info into the item. But maybe this is
still a better idea?


On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <pdherbemont at gmail.com>wrote:

> Then, there is nothing making the reference ownership clear here. When
> shall an item be _free? The usual convention is that you don't own the
> reference from a parameter unless it is retained/held. I wouldn't go too far
> away from here.
>

It sounds very usual to me also to see comments like this: /* the returned
value must be freed by the caller */


On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <pdherbemont at gmail.com>wrote:

> There should be probably one manual way to browse the tree of a given SD
> plus one way to register event for tree change. If we want to go that way.
>

I agree.


On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <pdherbemont at gmail.com>wrote:

> I was also wondering if the services_discovery_item_t couldn't be merged
> with input_item_t. Currently input items are also used as node, but they
> only send event that indicates a new subitems. They don't store their
> children. If this was changed then you gain tree support.
>

You see, here again, I wouldn't like to impose storing the tree structure by
design. I very much took Qt4's QAbstractItemModel as an example and you can
think of services_discovery_item_t as QModelIndex. The idea is that as a
client you have a token for an item and using that token you can by request
get tokens for items hierarchically below the former item. But there is
nowhere any implication about how they are stored, if they are really stored
hierarchically...

If we take shoutcast for example, the module can first issues out a top item
token that stores an url that will return genres. Upon request from the
client the module actually does that http request, but then it doesn't need
to store the genres anyway, instead it returns a list of child item tokens,
which again store only single URLs, which are enough to obtain stations
under each genre. And then again the same goes for actually obtaining
stations. You see, a simple url is all there needs to be stored in that
case, why would we impose actually storing the discovered items into a tree?

The above example explains also why such a shoutcast SD module couldn't
always return the same pointers for items. Because it never needs to store
them permanently. Instead, two items which have the same url stored should
be recognised as equal by some compare function, because they represent an
equal HTTP request, and will (should) have an equal result. Only the client
never knows what is actually stored into the items, that's the reason to
have module-defined compare function.

It would be all so much easier in C++ !

Best regards!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090901/fd9c81c9/attachment.html>