On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <span dir="ltr"><<a href="mailto:pdherbemont@gmail.com">pdherbemont@gmail.com</a>></span> wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<div>Why can't the client just listen to the event?</div></blockquote><br>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.<br>
<br>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.<br>
<br><br><div class="im"><div>On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <span dir="ltr"><<a href="mailto:pdherbemont@gmail.com">pdherbemont@gmail.com</a>></span> wrote:</div></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<div>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.</div></blockquote><br>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.<br>
<br>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?<br>
<br><br><div class="im"><div>On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <span dir="ltr"><<a href="mailto:pdherbemont@gmail.com">pdherbemont@gmail.com</a>></span> wrote:</div></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
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.<br></blockquote><div><br>It sounds very usual to me also to see comments like this: /* the returned value must be freed by the caller */<br> </div><br><div class="im"><div>On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <span dir="ltr"><<a href="mailto:pdherbemont@gmail.com">pdherbemont@gmail.com</a>></span> wrote:</div>
</div>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">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.<br></blockquote><br>I agree.<br><br><br><div class="im"><div>On Tue, Sep 1, 2009 at 2:16 AM, Pierre d'Herbemont <span dir="ltr"><<a href="mailto:pdherbemont@gmail.com">pdherbemont@gmail.com</a>></span> wrote:</div>
</div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div>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.<br>
</div></div></blockquote></div><br>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...<br>
<br>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?<br>
<br>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.<br>
<br>It would be all so much easier in C++ !<br><br>Best regards!<br><br><br>