[vlc-devel] Rust work (discussion)

[Alexandre Janniaux]

Actually Rémi's answer has the same point has me but much
clearer, I should have updated the mailbox first.

I'd like to also highlight that there's also a lot of effort
needed to write code currently, so rewriting existing code
is actually not directly improving the project, though it
could better match someone's preference when working on the
project. Writing new code in Rust seems to me much beneficial
to the future, and even has the benefit that it doesn't change
the code maintained by current non-rust developers.

On Sun, Sep 20, 2020 at 01:48:15PM +0300, Rémi Denis-Courmont wrote:
> 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/
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel