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

[Rémi Denis-Courmont]

Hi,

As long as everyone uses the same or interoperable API for threads, it doesn't matter if they are the same. We already have code using POSIX or Win32 threads and code using atomic waits. Some underlying libraries probably use other custom mechanisms.

(I considered forking the VLC thread code out to reuse elsewhere, but it's still not so trivially dependent on other VLC portability layers.)

Same points apply to sockets as well.

Now if Rust does not provide adequate facilities, you can wrap VLC code. But for the most part, I would expect that it's not afflicted with the same legacy run-time issues than C. Mostly we should wrap the relevant VLC object types, IMO.

Le 20 août 2020 14:05:56 GMT+02:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>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

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200820/d67acac2/attachment.html>