[vlc-devel] Re: [RFC] playlist current playing item for JS API
Damien Fouilleul
damien.fouilleul at laposte.net
Tue Apr 3 10:45:06 CEST 2007
I suppose libvlc_playlist_items_current() could return an item
identifier, just like libvlc_playlist_add_extended(), it would return 0
if nothing is being played, at least this would keep all APIs consistent.
and we could also write APIs such as libvlc_playlistitem_get_uri(itemID,
...), if itemID is 0 or not existent, and exception is returned
Jean-Paul Saman wrote:
> 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
More information about the vlc-devel
mailing list