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

[Pierre Ynard]

> 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.

But the goal totally wasn't to foster development of new scripts by the
community. That's why we never bothered setting up a website to host
them. </sarcasm>

> 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.

Firefox plugins are a huge asset for Firefox. So your comparison rather
speaks in favor of an external plugin ecosystem.

> 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.

I'm not 100% sure what you mean since I have trouble parsing your
sentence. But LibVLC provides VLC functionality to an application,
whereas the lua API provides functionality to VLC, so they're not quite
comparable.

Also I'm not sure that the use of LibVLC has contributed more to VLC
than the use of the lua API. Lua considerably lowers the bar for writing
code, and results in much faster contributions that add directly to VLC.

> 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.

That's FUD on your part. First result in google:
http://lua-users.org/lists/lua-l/2005-08/msg00564.html
I don't understand everything but it sure sounds like threading is taken
care of.

> 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...

We wouldn't. The locking would be handled by the C part of the API
layer. The semantics don't have to be complicated.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."