[vlc-devel] Re: [RFC] playlist current playing item for JS API

[Jean-Paul Saman]

Damien Fouilleul wrote:
> I agree, playlist_item_t should not be exposed to external API, we 
> should return an opaque pointer which may point to playlist_item_t, in 
> which case we need a way to control the lifetime of the playlist_item_t 
> data, so that the playlist does not destroy it while it is being 
> accessed by a public API, to do so, we can either use refcounting on 
> playlist_item_t or duplicate it.
> 

I found a libvlc_playlist_t in include/vlc/libvlc.h in which you can 
copy items from the current playlist item before returning to the user. 
This looks like the way to go forward.


> Damien
> 
> Clément Stenac wrote:
>> Jean-Paul Saman wrote:
>>> Zorglub,
>>>
>>> I need your comments on attached patch. The idea is to let a JS 
>>> programmer get information (incl. meta information like: media 
>>> length, index, name) on the current playing item.
>>>
>>> The patch currently expose playlist_item_t to the control api that we 
>>> use in the browser plugins. I don't know if this is supposed to be 
>>> done, so please comment on this.
>>>
>> Having this kind of info is suer needed, but I'm opposed to exposing 
>> the playlist_item_t structure. playlist_item_t is an internal 
>> structure that we should not tie to our public API. Moreover, exposing 
>> playlist_item_t means that you will also need to expose a huge number 
>> of internal structures (starting with input_item_t, then vlc_meta_t, 
>> input_category_t, es_format_t, vlc_mutex_t, libvlc_t, ...).
>>
>> What I wanted to do but did not complete was one of the two following 
>> solutions:
>>
>> * only expose to the client an abstract structure identifying the 
>> item. The client then only uses API functions to retrieve the fields, 
>> like:
>>   char* libvlc_playlist_get_item_uri(libvlc_instance_t*, libvlc_itemid_t)
>> * copy the required information to an external, stable structure and 
>> pass that to the client, like
>>   libvlc_itemdescr_t* libvlc_playlist_get_iteminfo(libvlc_instance_t*, 
>> libvlc_itemid_t)
>>
>> I think I prefer the first solution, which can be efficient if 
>> implemented with a cache. I think it's better because we can add new 
>> libvlc_playlist_get_item_* functions without breaking both API and ABI 
>> in a backwards-incompatible way.
>>
>> Clément
>>
> 

Gtz,
Jean-Paul Saman.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html