[vlc-devel] Rust work (discussion)

Rémi Denis-Courmont remi at remlab.net
Sun Sep 20 12:48:15 CEST 2020


Hi,

At this point, the only Rust related merge is to support Rust contribs. This 
should be almost totally orthogonal to either your or Kartik's work.

We are not at a point where we can consider porting the entire VLC to Rust. It 
is not only about the actual work of porting the code, which you have already 
started and advanced however far. Rust needs to support all combinations of OS 
and ISA that VLC does. Core developpers need to learn Rust. I think that the 
general assembly of VideoLAN probably needs to agree to switch over as well 
(and it probably won't be convened until the pandemic is over).

Kartik is proposing a mean to support optional plugins written in Rust. This 
by contrast does not raise any of the above problems(*). And I think that's as 
far as we can go for now. I am not worried that that work would be in vain: 
even if VLC eventually switches entirely to Rust, the design work in the API 
should prove useful. And given the scale of the project, this needs to be 
implemented step-by-step in any case. We can't just shutdown VLC for a year 
while we port it to Rust, just like you can't close a road while you convert 
it into a motorway.

The obvious next step would be to rewrite plugins that depend on Rust contribs 
in Rust, but even that kind of raised issues. Personally, I'd instead first 
like to have the MP4 demuxer and then the MKV demuxer ported to Rust because 
they seem to me like the most obvious beneficiaries. But I don't think even 
that is possible or acceptable yet, also for the same reasons.


(*) Though it begs the question what really is an "optional" plugin.


>  - On the front end, I have some awareness that there are other users
> of libvlc than the actual VLC binaries, but little knowledge of them,
> and am not in a good position to assess just how much of libvlc and/or
> core would need to be exposed to them to continue to support them via a
> C interface;

You need to preserve the LibVLC C API (include/vlc/*).

> how easily they might just learn to talk to Rust instead;

That is not realistic. It's not just C. People use LibVLC from all sorts of 
different languages and we are not in a position to decide for them. And AFAIU, 
the recommended mean to expose Rust to other language is to provide C 
bindings.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/





More information about the vlc-devel mailing list