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? >> 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, Are you sure about "definitely"? gchar is merely a typedef name for char... > and since we don't want that implementation detail > exposed in our plain C bindings, Yup, letting GLib's typedef names for ordinary C types leak into your public headers would be a mistake. > 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. [...] -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
