On Wed, May 22, 2019 at 10:08:44AM +0200, Markus Armbruster wrote: > Andrea Bolognani <abolo...@redhat.com> writes: > > > 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. > > Interesting. Got a link?
https://gitlab.gnome.org/GNOME/glib/issues/1484 Regards, Daniel -- |: 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
