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

[Alexandre Janniaux]

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?

Regards,
--
Alexandre Janniaux
Videolabs