On Mon, May 13, 2019 at 04:33:17PM +0200, Andrea Bolognani wrote:
On Mon, 2019-05-13 at 13:19 +0100, Daniel P. Berrangé wrote:
On Mon, May 13, 2019 at 02:00:28PM +0200, Andrea Bolognani wrote:
One possible complication is that we would not be able to use any of the GLib types in our public API... I think the way we should approach this is to consider the current public API as if it were yet another language binding, the language being plain C in this case, and make sure we have a very well defined boundary between them and everything else, basically treating them as a separate project that just so happens to live in the same repository and be developed in tandem. This should also make it easier for us to switch to a different programming language in the future, should we decide to.
I'm not sure why you say we can't use GLib types in our public API ?
I think we could use them, but I'd probably suggest we none the less choose not to use them in public API, only internally :-)
But I'm anticipating we could replace virObject, with GObject, and as such all the virXXXXXPtr types in our public API would become GObjects. I think we'd likely keep them as opaque types though, despite the fact that they'd be GObjects, to retain our freedom to change impl again later if we wish.
I won't think we need to change use of 'long long' to 'gint64', etc Not least because because GLib maintainers themselves are questioning whether to just mandate stdint.h types. This is fairly minor though.
I was mostly thinking about this latter example and other situations along those lines. For example, we'll definitely need to start using gchar* internally, and since we don't want that implementation detail exposed in our plain C bindings, then we'll have to do at least some very lightweight conversion (casting) between that and char*. This is one of the examples where considering the existing API as a language binding would IMHO result in a maintainable structure.
Another situation where the above model would help is error reporting: if we start using GLib heavily, then it might make sense to adopt GError as well, but doing so means we'd have to convert to our existing error reporting facilities somewhere. If we consider the plain C API to be a binding, then that's not different from what we already do for Python and friends.
Yep,I see what you mean.
As for GObject, yeah, we want all public structures to be opaque anyway; at the same time, we won't be able to turn existing non-opaque public structures into GObjects. I'm not sure how big of a deal that would be in practice, but I just thought I'd bring it up.
There is a concept called "Boxed types[1]" which lets you deal with plain C structs using the GObject system. It is good when you have a light weight struct where you want easy deep-copying but don't want the overhead of a full GObject, or where you're consuming structs defined by a 3rd party which you can't control. But as we seem to agree, I don't think we need touch anything in the public headers in the forseable future, so don't have to worry about that. Regards, Daniel [1] https://developer.gnome.org/gobject/stable/gobject-Boxed-Types.html -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|