GstMeta GTypes - API vs implementation?

[Sebastian Dröge]

On Wed, 2020-10-07 at 15:59 +0100, Neil C Smith wrote:
> 
> > I would also recommend you take a look at how GstMeta was wrapped in rust,
> > that might give you some more insight :)
> 
> Yes, I often refer to Rust and C# bindings, and looking to get more
> aligned - at some point given time/resources we'll be moving to
> auto-generation, and new additions tend to be made with that in mind.
> 
> So, with regard to Rust and Meta, the code eg. here seems to imply
> that the MetaAPI type is 1-to-1 mapped to the implementation type by
> MetaAPI::GstType?  My Rust-fu is limited still!
> 
> https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/buffer.rs#L399
> 
> https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer-video/src/video_meta.rs#L222
> 
> 
> That's a sort of pattern we could work with, as long as it's
> guaranteed to hold in all cases?

Maybe not. The current API in the Rust bindings is based on how the C
API is used in practice everywhere, not on how it could in theory be
used as that would complicate everything considerably and I don't see
it happening that someone ever actually makes use of that in the
future. If I'm wrong then it's not much of a problem and the API can be
updated :)

The reason for the split between two GTypes for the meta was (IIRC) to
be able to have some kind of inheritance. You could have one meta that
*also* implements another API, like a GstVideoMeta2 that is compatible
with GstVideoMeta. I don't see how this can be possible with the
current implementation in C and how it can be introduced at this point
without breaking a lot of code, so I'm not really worrying about that.

For all practical purposes, there are two GTypes for every meta, and
the reason for making that the API one in the Rust bindings is that
this is what e.g. gst_buffer_iterate_meta_filtered() works with.

-- 
Sebastian Dröge, Centricular Ltd · https://www.centricular.com