<div dir="ltr">Hi Remi,<div><br></div><div>I'm back working on this and was wanting to ask you a few follow ups question on this. Just to be sure i'll implement it correctly.<div class="gmail_extra"><br><div class="gmail_quote">
On Tue, May 27, 2014 at 2:18 PM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
So far, it seems you only want to clean up the directory expansion within the playlist, but not add dynamic updates. For that modest purpose adding a third read callback to access_t (pf_read_item or pf_readdir or something) should be sufficient. This allows replacing the XSPF generator from the directory plugin in a cleaner and more generic fashion. Then there is no problems with storing state (it can stay in the access_t plugin as before). The changes to the core would be much more contained, and I see absolutely no needs to reinvent the input thread.<br>
</blockquote><div><br></div><div>I'm wondering whether the pf_readdir callback should returns a input_item or an input_item_node :</div><div>- If we return a node, we can handle all the recursive nodes in directory.c, but we'll need to peek into the input_thread to get the parent input item.</div>
<div>- If we return a item, it will behave more like the real readdir function, and will allow for simpler item streaming between access and demux.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Your browsable flags would probably still be useful for fine tuning the playlist GUI, but not for the core.<br>
<br>
Either way, that won't solve dynamic node updates, so I doubt it will be good enough for UPnP.<br></blockquote><div><br></div><div>On that matter, i'm still really interested to know what are correct implementations for this. </div>
</div><br></div><div class="gmail_extra"><br></div></div></div>