[vlc-devel] Re: [RFC] playlist current playing item for JS API
Damien.Fouilleul at laposte.net
Mon Apr 2 23:04:12 CEST 2007
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.
Clément Stenac wrote:
> Jean-Paul Saman wrote:
>> 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
> * only expose to the client an abstract structure identifying the
> item. The client then only uses API functions to retrieve the fields,
> 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*,
> 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.
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