[vlc-devel] [PATCH] Add Rust backed cue sheet parsing module
robux4 at ycbcr.xyz
Thu Aug 20 12:27:43 CEST 2020
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:
>>> 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:
" 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.
>> we only have this binding to update.
> And the Rust code using these bindings.
> (Unless the Rust bindings API is not a 1-to-1 matching, but exposes some
> "stable" API, different from the core API, instead.)
>> And then we could do the same kind of generic binding for codecs and pretty
>> much every other module type.
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel