[vlc-devel] CIL bindings and brain dump on LibVLC

[Rémi Denis-Courmont]

	Hello,

If you read the commit logs, you would have noticed I added some preliminary 
bindings for LibVLC for the Common Intermediary Language, in other words 
DotNet. These are IN NO WAY a replacement for the ActiveX plugin, since these 
do not provide an ActiveX plugin. However they do run where the ActiveX 
won't - beyond Win32 - or would be suboptimal - any "managed" application.

This brought several issues to my mind.

First, I was badly confused with the old mediacontrol_ APIs still being there. 
libvlc-control is now a nasty mess providing two competing APIs - in the same 
shared object! Second, the mediacontrol_ ABI has been silently broken from 
0.8.6 (contrary to the promise not to do so). I am considering reverting my 
changes to mediacontrol, but that won't solve this problem. As such, I would 
really consider REMOVING mediacontrol_ from 0.9.0 completely.

Now on the new LibVLC:

For the reference, CIL provides a grand total of six integers types, which 
corresponds to the following C99 types: int8_t, int16_t, int32_t, int64_t and 
intptr_t and bool. Note that "int" is not directly supported - I am currently 
assuming it is int32_t, which works by far on most platforms (at least all 
32-bits platform as well as x86_64). But it might break :-(
I am not too sure about bool. Within Win32, BOOL maps to 32-bits, but I 
suspect gcc maps bool to 8-bits on the same Windows platform :-(
And then, same problem with enum, which compilers are free to map to any "big 
enough" integer type.
It gets interesting when you consider that you cannot provide native "glue" C 
code here, since it would defeat the whole CIL concept of "compile once, run 
anywhere". In other words, any piece of code beyond libvlc-control is to be 
compiled in CIL. So basically, anything that uses int may be somewhat broken, 
and anything that uses bool or enum is somewhat more likely broken.


The other big problem I have had is the lack of reference counting on 
libvlc_instance_t. The garbage collector ensures that any allocated 
libvlc_instance_t will be released with libvlc_destory, but it cannot warrant 
that any other dependent LibVLC object such as a media instance or a media 
descriptor will not similarly be released *after* libvlc_instance_t... and 
then, it does actually crash the whole process :-(
I would really prefer that libvlc_instance_t be reference counted, yield 
whenever a dependant object is allocated, and released whenever it is 
destroyed, so that it may survive beyond libvlc_destroy if needed. There is 
support for reference counting the handle in CIL, but I think it would be 
clumsy to do so.


Last topic is build system integration. As I already noted for other language 
bindings, I suspect it would be a terrible idea to include these in the VLC 
tarball and build these within the VLC build system. How likely are 
distributors to add yet another big dependency (the whole .Net SDK or Mono) 
to our monolithic build scripts? not much. Especially if I look at the 
current state of binary packaging the Python and Java bindings...
Besides, thanks to "compile once run anywhere", there is no need to recompile 
this for all platforms. Also, it does not at all depend on libvlc.h or 
libvlc-control.la anyway, as CIL uses dlopen-style imports, with 
CIL-translated function prototypes.

Then it all comes down to, where should the source code be stored?


-- 
Rémi Denis-Courmont
http://www.remlab.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071021/8cbb40bd/attachment.sig>