On Wed, May 22, 2019 at 10:08:44AM +0200, Markus Armbruster wrote:
Andrea Bolognani <abologna(a)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 :|