<div>
<div>I feel like I need to make a recap about the core issues that i'm more concerned right now:</div>
<div> </div>
<div>1. Notifications: I'd leave it at having a single event manager per SD instantiation.</div>
<div> </div>
<div>2. Per-node fetching of children: I mean introducing novelties into SD core API, basically starting with this:</div>
<div> </div>
<div>struct services_discovery_item_t</div>
<div>{</div>
<div>   VLC_COMMON_MEMBERS;</div>
<div>   bool b_fetched;</div>
<div>   int i_children;</div>
<div>   struct services_discovery_item_t** pp_children;</div>
<div>   // ...</div>
<div>}</div>
<div> </div>
<div>services_discovery_FetchChildren( services_discovery_item_t *p_parent );</div>
<div> </div>
<div>In response to which a module issues item(s)-added event(s), when it has filled the p_parent with children. It uses the same events for notifications originating from monitoring it's service source. Generically: the event is issued anytime the pp_children array changes after the first fetch request for that node has been issued.</div>

<div> </div>
<div>As long as a set of tree hierarchy has been fetched, it's navigatable simply by examining i_children and pp_children fields, provided that the SD instance's lock is held.</div><br> </div>