[vlc-devel] [PATCH 00/10] Item browsing system
Felix Abecassis
felix.abecassis at gmail.com
Mon May 26 15:10:45 CEST 2014
2014-05-26 11:41 GMT+02:00 Julien 'Lta' BALLET <elthariel at gmail.com>:
> From: Julien 'Lta' BALLET <contact at lta.io>
>
> Hi vlc-devel,
> Hi core maintainers,
>
> I've been working recently on a tiny library implementing SMB with an
> iOS compatible license and was about to start writing a vlc module for
> it. A smb module should have 3 parts:
> - Discovering other infected machines.
> - Browsing shares and folder inside of shares
> - Reading files
>
> While VLC has way to handle the first and last part. The middle one,
> browsing, seems to be an issue. After searching through VLC's code,
> i've found a solution in access/directory.c but not really the kind of
> solution i wanted to reproduce (it generates XSPF on-the-fly).
> After discussing the issue with j-b and felix, it appeared that they
> were similar concerns for UPNP and Bonjour.
>
> Here's then a patchset implementing a browsing system for input_item_t
> i'd like to submit to your expert attention.
>
> Why a browsing system ?
>
> - I'm working on a SMB client with an iOS compatible license and was
> about to integrate it when i discovered access/directory.c. I
> don't want to implement SMB browsing the same way.
>
> - Improving media discovery: Some service discovery protocols needs
> to forward items to other modules. A typical example is
> mDNS/Bonjour (works for UPNP as well). Bonjour allows you to
> discover services that use other protocols. When the Bonjour SD
> finds an ftp server, he cannot tells the user what's inside of the
> ftp server, that should be the responsability of a ftp module. So
> he needs to forward the discovered item (ftp://srv_addr) to
> another module which speaks ftp.
>
> - Media discovery and browsing is a different job than the core
> media playback and streaming (input). Improving media discovery
> shouldn't make the core more complex. On the other hand,
> extracting browsing features to another subsytem will prevent
> people working on discovery and browsing to introduce bugs in the
> input core.
>
> - The lack of a proper item browsing system has led to clever but
> still somewhat dirty hacks, like on-demand generation of XSPF
> playlist when 'playing' a folder.
>
> - Making playlist files handling simpler.
> 1. It'll be possible to mutualize some item_node handling code
> from playlists and to reduce coupling between core playlist
> and modules.
> 2. It'll allow to move playlist parsing modules out of the demux
> system and folders.
> 3. It'll make the playlist modules have a simple API and data
> structures (no seek, no ES, no control).
>
> - (It'll allow for playlist filters, althought i haven't found
> precise use cases for that. So let's no count that one.)
>
> What do i mean by 'browsing system' ? There's two things:
>
> - A new type of module: 'browse' module, whose job is to take an
> input_item_t (and optionnaly a stream) as an input and to fill an
> input_item_node_t as its output. Basically it's meant to read
> folders, playlists, discovery protocol and APIs.
>
> - A (very) lightweigt clone of the input_thread_t to handle the
> browse modules: browser_thread_t. The browser thread is integrated
> to the playlist loop, to have a consistent behavior with what
> happens with input.
>
> How it works ?
>
> - Browse modules have a very simple API: They expose only a
> pf_browse function. They receive an input_item_t item to browse,
> optionnaly a stream_t and a input_item_node_t to fill.
>
> - There are two kind of browse module. access_browser and browser.
> - access_browser are for browsing folders at a low
> (system/protocol) level (local, ftp, smb folders).
> - browser requires a stream_t and handle files/streams (API,
> playlist files).
>
> - Browsing thread looks like input_thread_t. While it carries most
> of its looks and behavior (events, state, API), it is much much
> simpler. He runs on it's own thread but will soon gain a
> synchronous and simpler API for usage in UIs.
>
> - Item gets a few flags (browsable/alread browsed) to handle node
> going back and forth between input and browsing.
>
> - When the playlist tries to play an item with the browsable flag
> it starts a browser thread instead of an input one.
>
> - input modules (especially access) have the opportunity to mark
> item as browsable, making the playlist retry them in the browser
>
> - A rewrite of access/directory.c is included to demonstrate this.
> A browser version of wpl playlist module is working, but needs some
> cleaning before submission.
>
> What still needs to be done ?
>
> - Gather all the precious constructive comments i hope to receive
> here and fix my code.
>
> - Implementing a fallback mechanism to try items in the browser if
> input was unable to read them, even after the PS input fallback.
> (BTW: I'm very curious about this, why PS is the input fallback ?)
>
> - Implementing a simple API call on top of that, in the spirit of
> input_Read()
>
> - Move playlist parsers to this system.
>
> All those item will be handled in about two weeks, after i finish
> preparing and giving an intensive week-long class in a french school.
>
>
> If you read this line, i thank you for the time you spent and encourage
> you to go forward and review the patchset :)
>
>
> Cheers,
> Lta.
>
> Julien 'Lta' BALLET (10):
> Adds a flag field in input_item_t. Adds browsable and already browsed
> flags enum definition
> Adds accessors functions for input_item_t flags
> Adds categories and help for browse modules
> Adds a new browsing facility whose job is to browse/expand items like
> folders, playlist or item from APIs.
> Adds INPUT_EVENT_BROWSE
> Adds VLC_ENEEDBROSE and make input report an item need browsing
> Integrates browsing inside of the playlist
> Moves a usefull function of access/directory.c from Remi
> Denis-Courmont to src/text/url.c
> Rewrite access/directory.c as an access_browser. No more xspf
> generation ... Yeah!
> Let's not fetch art for browsable items
>
> include/vlc_browsing.h | 138 ++++++++++
> include/vlc_common.h | 2 +
> include/vlc_config_cat.h | 13 +
> include/vlc_input.h | 4 +
> include/vlc_input_item.h | 12 +
> include/vlc_plugin.h | 2 +
> include/vlc_url.h | 1 +
> modules/access/directory.c | 537
> ++++++++++++++++-----------------------
> modules/access/file.c | 29 +--
> modules/access/fs.c | 5 +-
> modules/access/fs.h | 3 -
> src/Makefile.am | 5 +
> src/browser/browse.c | 106 ++++++++
> src/browser/browser.c | 348 +++++++++++++++++++++++++
> src/browser/browser_internal.h | 48 ++++
> src/browser/event.c | 55 ++++
> src/browser/event.h | 36 +++
> src/input/event.c | 6 +
> src/input/event.h | 1 +
> src/input/input.c | 52 +++-
> src/input/item.c | 48 ++++
> src/libvlccore.sym | 5 +
> src/playlist/engine.c | 1 +
> src/playlist/fetcher.c | 4 +
> src/playlist/playlist_internal.h | 16 +-
> src/playlist/thread.c | 194 ++++++++++++--
> src/text/url.c | 38 +++
> 27 files changed, 1329 insertions(+), 380 deletions(-)
> create mode 100644 include/vlc_browsing.h
> create mode 100644 src/browser/browse.c
> create mode 100644 src/browser/browser.c
> create mode 100644 src/browser/browser_internal.h
> create mode 100644 src/browser/event.c
> create mode 100644 src/browser/event.h
>
> --
> 1.9.3
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
nitpick: please use the imperative style for commit messages, e.g. use
"add" instead of "adds" or "added".
--
Félix Abecassis
http://felix.abecassis.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20140526/5f249270/attachment.html>
More information about the vlc-devel
mailing list