Rémi Denis-Courmont
remi at remlab.net
Sun Sep 20 12:48:15 CEST 2020
More information about the vlc-devel mailing list
Sun Sep 20 12:48:15 CEST 2020
- Previous message (by thread): [vlc-devel] Rust work (discussion)
- Next message (by thread): [vlc-devel] Rust work (discussion)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/
- Previous message (by thread): [vlc-devel] Rust work (discussion)
- Next message (by thread): [vlc-devel] Rust work (discussion)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the vlc-devel mailing list