[vlc-devel] core playlist

[Pierre d'Herbemont]

On Fri, Aug 28, 2009 at 1:25 PM, Jakob Leben<jakob.leben at gmail.com> wrote:
> 2009/8/27 Rémi Denis-Courmont <remi at remlab.net>
>>
>> Le mardi 25 août 2009 19:07:06 Jakob Leben, vous avez écrit :
>> > The plan is therefore to implement
>> > obtaining/accessing input items via SD and ML directly in every
>> > interface
>> > that needs SD and ML.
>>
>> Yes *but* this does not specify whether each interfaces would have its own
>> instance of SD and ML. It would be simpler, but in some cases it wouldn't
>> work
>> at all. In fact, the ML is a single database. And, say an MTP device can
>> probably only be used by one entity at a time... So I suspect you still
>> need
>> to manage SD and ML models in the core.
>>
>> > Thus further changes to playlist functionality could be done much
>> > easier.
>> > Eventually, playlist_t could store only a simple list of input items,
>> > that
>> > would represent a flat actual "now playing" playlist, so this would not
>> > even need playlist_item_t. Of course, every input item to be played
>> > should
>> > then be inserted into this exact list, which I believe we agreed upon as
>> > the preferred functionality.
>>
>> Yes but first the new SD and ML back-ends must be implemented.
>
> I am working on a new SD API. Basically, It's just an extension of the
> current API. It features a new struct to represent a SD item and allows for
> traveling trees of such SD items, where a SD plugin does the actual info
> retrieving. Every SD item can be queried for media - so that there can be
> non-media (non-playable) items, to represent pure "directories" or groups of
> subitems. If a SD item has media, an input_item_t can be obtained from it.
> The idea is that ultimately we only get input_item_t that are actually
> playable, and can thus be inserted into the (future) flat playlist.

You should probably post here your API (not the patch first) once you
have a good vision of it so it can be discussed.

Pierre.