[vlc-devel] [vlc-commits] lua: remove add_callback and del_callback

[Rémi Denis-Courmont]

On Fri, 30 Mar 2012 01:36:38 +0200, Pierre Ynard <linkfanel at yahoo.fr>
wrote:
>> The _internal_ plugin API is explicitly unstable across major
>> versions. As far as VLC Lua exposes (a subset of) that API, it is
>> unavoidably unstable as well. So that is a red herring
> 
> Well... isn't this retarded? Shouldn't that lua API be made stable,

No. The goal of Lua was to ease maintainance of some
non-performance-critical code. For instance, parsing playlist in C is hard
and error-prone. Lua does this very well.

Keeping the API stable would require some level of abstraction away from
the unstable core API, as for LibVLC. I don't think we have spare resources
to waste on this, but as I said, you are free to write LibVLC bindings in
Lua. In any case, this definitely precludes exposing configuration items,
objects, object variables, and variable callbacks. By the way,
configuration items are already explicitly marked as unstable/unsupported
in the LibVLC documentation.

> if we want to encourage external developers to use it? Lua functions
> don't have to match plugin API functions, that's not necessarily a good
> design. So ultimately that's not an excuse to be careless.

I don't particularly want developers to use it externally, precisely
because this is going to keep breaking _and_ we, the core developers, have
little to no visibility on external plugins. This is really just like Linux
kernel modules or Firefox plugins. You can write them, but you have to
expect that it will break sooner or later.

I definitely don't intend to keep the core API stable, of which the Lua
API is a large subset.

(...)
> That's an interesting point. Also, external developers don't know
> anything about objects and variables, that are VLC internals. So this
> API makes it hard for them to take advantage of all the possibilities
> (for polling-free code) that this offers.

If you want mashed mostly stable events, you have LibVLC.

I am opposed to defining a third (or even forth if you count Skins XML as
an API) to LibVLC, at least not until we have adequate resources to
maintain LibVLC. IMNSHO, LibVLC is higher priority than external Lua.

>> So there would be memory barriers and mutual exclusion. That does not
>> prove that the Lua interpreter can deal with this.
> 
> It seems not to explode all over the place. What could be wrong with
> this, and how can we prove whether it can actually work or not?

You would need to check with upstream. You cannot prove it. Even if you
read the code, upstream can always undo properties that it did not commit
to.

And I don't think we should expose thread and locks to Lua. The point of
introducing Lua was to make programming easy and safe...

>> Also, that would turn the Lua plugin into a maintenance hell, as you
>> would need locking all over the place.
> 
> That's a bit pessimistic. You could say that you only need to lock in
> callback functions and functions that put the main thread to sleep.

You might as well write the callback function in pure C, and keep the Lua
interpreter away from threads then.

-- 
Rémi Denis-Courmont
Sent from my collocated server