[vlc-devel] [RFC: PATCH 1/2] libvlc: Add Rust API for writing modules in rust

Romain Vimont rom1v at videolabs.io
Thu Sep 10 22:36:30 CEST 2020


On Thu, Sep 10, 2020 at 10:43:49PM +0300, Rémi Denis-Courmont wrote:
> 	Hi,
> 
> Manually wrapping the API sounds like a lose-lose proposition, as not all core 
> developers know Rust in general, and/or Rust C bindings in particular, and you 
> cannot expect/require them to update Rust code. This raises two separate 
> questions:
> 
> 1) Why are the bindings not generated automatically? Rust has tools 
> specifically for this purpose. VLC is not particularly heavy on preprocessor 
> macros so automatic binding generators should work just fine - or then, *they* 
> need to be fixed.

There are typically 2 layers:
 - one with generated bindings matching 1-to-1 the core API;
 - a safe wraper to expose a rust-idiomatic API.

The second part may not be automated. For example, the ownership
information is not available from the C API (except in the
documentation).

Also, from the Rust-side, we want a Rust API, not a C API. For example,
we don't want to pass an array to a function as a raw pointer and a size
(but as a slice instead). Some wrapper types should also implement some
traits (it makes sense that a VLC Stream implements the std::io::Read
trait in Rust, so it's convenient to use).

> 2) Who's in charge of updating the Rust modules when the core API changes? We 
> can't expect all developers of core patches to know Rust, and know it well 
> enough to update Rust code properly. FWIW, I believe that only a minority of 
> the TC knows Rust well at this point in time even, not to speak of the broader 
> vlc-devel active membership.

One major goal of these experiments is to find a solution which allows
both to create Rust modules easily and does not require to update Rust
code too often.

A possible compromise is to expose a specific "simplified" API, stable,
in C, wrapped in Rust, to expose only specific features of the real core
API.

Thomas Guillem wrote:

> A Rust demux module could have a demux() function that read data via
> vlc_stream and send the result via some rust callbacks. The C module
> wrapper is then propagating these callbacks to es_out controls.

https://mailman.videolan.org/pipermail/vlc-devel/2020-August/136347.html

That way, the core API changes should not require to update the Rust
bindings and modules often (updating the C part of the simplified API to
maintain the stable Rust API should be sufficient).

(cf full discussion:
https://mailman.videolan.org/pipermail/vlc-devel/2020-August/thread.html#136231)

Regards

> Professional (sponsored) developers may or may not be granted the time and 
> material to train any time soon. And hobbbyists - in particular, but not 
> limited, to TC members David, Denis and myself* - are potentially in an even 
> worse position. And this problem is _not_ on the same level of difficulty as 
> with C++ and Objectionable C.
> 
> (*) I did buy a Rust book out of my own pocket, but it's unclear if/when I'll 
> have the time to actually read and assimilate it, regardless of motivation.
> 
> -- 
> Реми Дёни-Курмон
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list