[vlc-devel] [PATCH 08/10] Removes xspf generation in access/directory.c in favor of new pf_readdir callback

Julien 'Lta' BALLET elthariel at gmail.com
Thu Jun 19 11:29:26 CEST 2014

On Mon, Jun 16, 2014 at 8:05 PM, Rémi Denis-Courmont <remi at remlab.net>

> If I had a better idea than device and inode matching, I would have
> implemented it already by now (or at least filed a bug). Recursion limit
> does not work; we tried before. The old value, 5, was too much to prevent
> explosive recursion, and yet too low for some real use cases. Besides, what
> component would enforce the recursion level limit with the new model?
The idea here is to move all recursion related features to
modules/playlist/directory.c so it can be shared accross all browsing
module (smb, fs, and in the future, ftp, zip, etc.). Afaik, smb, ftp and
http don't provide any data that would allow us to limit recursion like the
device/inode couple do for filesystem, this leaves the filesystem browsing
as the exception rather than the rule. This also mean we'll have to rely on
the user to be clever when using this recursion feature (sic).

As the filesystem is the exception, maybe could we think about using a
small hack to handle this, like storing the device/inode couple as an
info_t on the input item ? This way i'll be able to walk up the tree in
playlist/directory.c to prevent such infinite recursion.

The last solution, which is definitely not my favorite, is to keep
pf_readdir modules for browsable access that can't handle infinite
recursion like smb/ftp/zip and such. This would mean keeping the xspf
generation in the fs module but would allow me to move forward on the other
browsing systems.

What do you think Remi ?

Best regards,
Julien 'Lta' BALLET.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20140619/d23573c1/attachment.html>

More information about the vlc-devel mailing list