[vlc-devel] [PATCH 00/10] Item browsing system

[Rémi Denis-Courmont]

Le 2014-05-27 17:30, Julien 'Lta' BALLET a écrit :
> On the other hand, having the state somewhere inside of input_item_t
> doesnt mean it has the share the same lifetime.

I think that's impossible. As long as the input item exists, it might 
potentially be expanded ("browsed into"). So as long as the input item 
exists, the state will need to be retained.

> Lets face it, at
> some point, any solution not including rewriting the playlist will
> have to work at least a little bit with the input_item. I wont say
> it makes me happy, but doin
> ight be out of a realistic time frame for me alone :) (Any help on
> that topic is welcomed, please drop in the thread if you feel like a
> warrior)

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.

Your browsable flags would probably still be useful for fine tuning the 
playlist GUI, but not for the core.

Either way, that won't solve dynamic node updates, so I doubt it will 
be good enough for UPnP.

> As a sidenode about inotify, theres another issue related to the
> "outstanding file handles/ what-nots issue": by default, the number 
> of
> watches allowed per-user by the kernel is pretty low, that mean we
> might have to choose which file we want to watch.

Oh sure. That's why I said you need more state than a single pair of 
flags to support dynamic node updates. I would guess you need to know if 
a least one UI is (still) showing that node expanded.

-- 
Rémi Denis-Courmont