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

[Julien 'Lta' BALLET]

On Mon, May 26, 2014 at 1:13 PM, Rémi Denis-Courmont <remi at remlab.net>wrote:

> Le 2014-05-26 18:53, Julien 'Lta' BALLET a écrit :
>
>  I do not assume directories are serializable. The browse module
>> receive a stream_t when you are trying to access an API over http, but
>> not when you a trying to browse a folder.
>>
>
> But that's exactly the problem. How do you pass the file descriptor from
> the access to the whatever-browser after (only after) fstat() tells you it
> is a directory? This is not serializable, so it cannot be passed via the
> input_item_t.


Currently, i don't pass the fd from the access to the browser. Considering
the number of fd that are open during browsing, i thought that one more or
one less wasn't a critical matter. Right now, the access just marks the
item as browsable and exits, the browser will re-open the fd.

On the other hand, for remote browsable node, sharing a state would
actually be pretty nice to speed things up.
A solution could be adding a vlc_object_t state to the input_item_t in
order to store a state, it's origin and handling its cleanup. We can even
make the input_item_t a vlc_object_t, as vlc_object_t have been simplified
a lot since the time input_item were created (at the beginning of times).
Do you think one of this is a proper approach to the issue ?


>
> Not to mention the hypothetical thread running inotify to detect
> asynchronous changes to the directory content. That also needs some life
> cycle management and can obviously not be serialized.


I never wanted to serialize anything. I'm trying to _remove_ xpsf
serialization :)

This asynchronous inotify thread seems to me like a whole other issue. I'm
not sure i realize all the implications of it. But i kinda feel the event
management mechanism and the gc should allow for implementing it ? I mean,
the worst case is when an item is currently being played and it gets
deleted but in that case, either the system will wait for the last fd to be
closed to actually delete the item or the access will fail and we'll be
able to release the item, no ?



>
>  In that case, the module has
>> to assume the access role (access_browser, much like access_demux).
>> The access_browse is likely to be part of the same .so that the
>> regular access
>>
>
> Using the same shared object solves sharing code, not sharing state.


Indeed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20140527/ce0d8fa5/attachment.html>