Hello world,<br><br>I propose the change / addition / upgrade to Services Discovery interface as indicated by the attached patch to vlc_services_discovery.h, which addresses issues that I have come across when working on and dealing with the current SD and playlist implementation.<br>
<br>Most notably it allows the following three features:<br>- SD modules can publish items in unlimited depth of hierarchy<br>- It is on clients to decide whether and when they want the SD to fetch and fill the children of a particular parent item.<br>
- It allows SD clients to distinguish pure container items from others that can actually be played.<br><br>As a bonus cool feature that I don't really see an actual purpose yet :), it allows SD modules to provide items within their item tree that are obtained and controlled from other SD modules.<br>
<br>A detailed explanation of the proposed functionality is in the patch, but I also post it here for instant preview.<br><br>You are very welcome to comment and to constructively brainstorm on any conflicting SD usage case that I might not have foreseen or anything that might be an obstacle to implementation of the proposed interface.<br>
<br>Please note that this is rather a sketch proposal than an actual patch to be applied.<br><br>Best regards,<br><br>J.L.<br><br>/******************************************************************************<br>  VLC Services Discovery Protocol:<br>
<br>  A SD client creates and starts a SD service.<br><br>  The service will provide a tree structure of nodes of type sd_node_t that may<br>  or may not be associated with actual playable items at their p_input_item<br>  field. The b_is_container field of a node indicates if any children can be<br>
  provided for that node. Typically, container nodes will not themselves be<br>  associated with any playable items (p_input_item == NULL).<br><br>  The method by which the service provides nodes is as follows:<br><br>  The service fills a particular parent node with children only AFTER the client<br>
  requests so with services_discovery_Fetch(). If b_is_container field of the<br>  (parent) node is false then trying to fetch children should do nothing, and<br>  the opposite: the service should set the field to true if children can be<br>
  provided for that particular (parent) node.<br>  For every child node provided, the system will emit an "item-added" event.<br><br>  The b_has_live_update field of a node indicates that the service is able to<br>
  spontaneously and continuously update the set of node's children AFTER the<br>  children have first been fetched AND the client has requested updating with<br>  services_discovery_SwitchLiveUpdate(... , true). For every child node<br>
  added/removed an "item-added"/"item-removed" event will be emitted.<br><br>  Already when started up, the service provides the abstract root node at its<br>  p_root field, of which children will be the actual meaningful nodes.<br>
<br>  Except for i_children, pp_children and p_parent, no fields of sd_node_t should<br>  be modified after it has been "published" by the service.<br><br>*******************************************************************************/<br>