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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
