[vlc-devel] [PATCH] Add Rust backed cue sheet parsing module

[Alexandre Janniaux]

Hi,

I agree that, from the Rust developer side, having the VLC API
being usage is really really good. However it's the opposite of
what Steve said, meaning mandatory maintenance of Rust code
with C code.

I'm not against the idea, since what is really needed is quite
usual and I personnally already do this with java / objc / C++
code, but it's important that it doesn't land in the core like
a false promise.

The main question here is then, where should this API be?

If we land it into VLC Core, it might not be accessible in crate
repositories (I'm not confident on this, but someone might
clarify what is planned here), thus not really allowing to write
out-of-tree VLC plugins, which is a shame given how the rust
ecosystem works. But if we land it into an external repository,
we might not have the plugins in-tree and it needs synchronized
maintenance.

How can this be solved? Maybe with a mixed solution?

Regards,
--
Alexandre Janniaux
Videolabs

On Thu, Aug 20, 2020 at 02:05:56PM +0200, Thomas Guillem wrote:
> I think we could port some VLC Core API to Rust like:
> - vlc_stream
> - socket/network/i11e
> - thread
>
> I think it's important for socket and thread since it's better to use only one implementation for those in one application.
>
> For this example, if the vlc_stream API was ported, the Rust API could have a Demux() function like VLC demuxes and the Rust code would take care of reading its own stream.
>
> On Thu, Aug 20, 2020, at 13:16, Steve Lhomme wrote:
> > On 2020-08-20 13:08, Alexandre Janniaux wrote:
> > > Hi,
> > >
> > > On Thu, Aug 20, 2020 at 12:27:43PM +0200, Steve Lhomme wrote:
> > >> On 2020-08-20 11:02, Romain Vimont wrote:
> > >>> On Thu, Aug 20, 2020 at 10:13:05AM +0200, Steve Lhomme wrote:
> > >>>> On 2020-08-19 17:22, Alexandre Janniaux wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> On Wed, Aug 19, 2020 at 05:04:08PM +0200, Rémi Denis-Courmont wrote:
> > >>>>>> And then I would expect that the interface from Rust is not ad-hoc, but rather wrapping the plugin API directly.
> > >>>>>
> > >>>>> I'm not sure to understand this correctly.
> > >>>>>
> > >>>>> Does it mean that rust should use vlccore function for the plugin
> > >>>>> behaviour, or that the plugin should directly expose itself without
> > >>>>> a C wrapper, or something else?
> > >>>>
> > >>>> Have generic Rust code that handles the VLC filter API and then each filter
> > >>>> be written in Rust without caring of the C binding.
> > >>>
> > >>> This is basically what Geoffroy Couprie did few years ago:
> > >>> https://www.youtube.com/watch?v=YTy_JOxGOd4
> > >>
> > >> " i skipped the video because of the french accent."
> > >>
> > >>> This is great, but the problem IMO is that it is too intrusive in
> > >>> practice: wrapping the core API (which is not "stable" like libvlc) in
> > >>> Rust implies that every core API change must be reflected to the
> > >>> wrapper/bindings (+ not all C developers are Rust developers).
> > >>
> > >> I wasn't talking about the core but the plugins. Each plugin type would be a
> > >> Rust "class".
> > >>
> > >> The plugin API's are rather stable compared to the core API. And the Rust
> > >> binding for each plugin type would be responsible to talk to the core. Just
> > >> like we update plugins when we change their API or the core API.
> > >
> > > What you seems to write is basically write this module in
> > > pure rust without C wrapper then, right?
> >
> > yes the minimum is done in C, just to plug the core to the module/plugin
> > API. On the other hand it becomes tricky to call VLC core API's from
> > Rust, which this module doesn't seem to need. But eventually some module
> > may need to do that.
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel