[vlc-devel] [PATCH] Add Rust backed cue sheet parsing module
robux4 at ycbcr.xyz
Thu Aug 20 13:16:01 CEST 2020
On 2020-08-20 13:08, Alexandre Janniaux wrote:
> 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:
>>>>> 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.
> 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.
More information about the vlc-devel