[vlc-devel] Rust work (discussion)

[Lyndon Brown]

On Sun, 2020-09-20 at 13:48 +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.

Sure. I appreciate that at this time the project officially is just
barely getting started with early explorations, and my Rust work even
now is very much out of step with that.

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

Of course. My project is not going to be completed this year, nor next
I'm sure; it's going to take a lot of additional time and effort.
There'll be plenty of time I'm sure for core developers such as
yourself to learn Rust, for discussions at VideoLan and between the
core team to take place about such a move, and at any rate, if it is
accepted eventually, then even once my project matures to a suitable
state to get the team more fully involved towards a switchover, it'll
take significant time and planning to review things and try to smoothly
transition things over. A fully Rust VLC is a long way off from being a
reality even with my work having brought that reality closer. There's
absolutely no expectation of it happening any time soon, nor absolute
expectation that it will definitely be accepted, and I recognise that a
switchover will not be a perfectly smooth ride in terms of any
incomplete C work that exists at that time for instance. :)

In terms of OS and ISA support. I would expect that by now Rust support
already covers the vast majority of VLC user platforms. But of course I
can appreciate that a proper review will be wanted to consider what
precisely is covered and what is not and whether or not loosing any of
them is acceptable.

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

No of course, but as I tried to covey, what I was trying to achieve was
to throw myself at doing the conversion work myself, or at least a lot
of it, in parallel to the continuous work on the C codebase by those on
the team such as yourself, keeping it in sync via rebasing, then
enventually present it to the team; with a suitable plan then being
setup by the team to co-ordinate getting the big review, testing and
switchover done with minimal disruption. I would not necessarily expect
those latter aspects involving the team to take a full year of effort,
though who knows, and I'm certainly not expecting other team work to be
suspended for a year to work on performing conversion.

I recognise that with Kartik's compatibility interface in place, one
benefit of that is that presuming that this subsequently enables a
steady incremental conversion of plugins to take place, that then by
the time my project is ready, a good portion of the plugins will likely
already be done, thus reducing the effort required in the big review of
my project, which may be very much appreciated by the team, and worth
the effort put into the compatibility interface.

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

Yes I'd agree that they are excellent candidates for conversion. In
fact I did put the effort into doing basic syntax conversion of the mp4
plugin code, but did not get any further than that, and it wasn't
really the right moment to properly focus on that, I was just over
eager to try tackling it. :p

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

Yep.

> >  - 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/*).

Ok, I figured so.

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

Sure. :)