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

[Rafaël Carré]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rémi Denis-Courmont a écrit :
> 	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.

+1

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

does that mean we should use some custom vlc_int type, to be sure to
know the size of the different VLC structures ?

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

Leaving it in the VLC source would allow for easier maintenance.

The cons is that packagers would need to build CLI bindings while
building VLC, since it's in the same source package, and so adding an
extra dependancy.

A solution would be to make a tarball of trunk/bindings/cli when
releasing, and so making lazy packagers happy.

- --
Rafaël Carré
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHG7EUYWCeGMCv8Q8RAssvAJwM8KHOSXYRYvwXUIzgQ6itY3QWywCgkUPg
pr74bdrOPBjByoJNUviqRfI=
=GDXZ
-----END PGP SIGNATURE-----