On Thu, 2009-10-15 at 10:54 -0400, Ryan Lortie wrote: > > - Make the code available in libgio (perhaps with the libdbus-1 using > > implementation in e.g. GVfs through GIOExtensionPoint - maybe not > > worth the effort) > > This would have the advantage of forcing a good design upon us -- the > convenience API would be forced to have very low coupling with > libdbus-1. It would also prevent future hackers from accidentally > introducing more 'surface area' between these components. > > There are a few approaches we could take to this end. All of them > assume that the user-facing API lives in libgio and that we use a GIO > extension point. > > 1) We could include the libdbus code directly in libgio.so and > internally register the extension point implementation. > > 2) We could include the code for libdbus in gio/ but have it > build a separate .so file that gets installed into the GIO > modules directory. > > 3) We could put it in GVFS.
Yeah, hmm, while this is theoretically nice and everything, I'm not sure it's worth the effort to do just yet. I think it's better to just ensure that libdbus-1 is available (and working) on all platforms where we care about GLib (e.g. Unix-like, Win32 and OS X). (Also, one side-effect is that all methods on GDBusConnection would need to use vfuncs with the incurred cost of doing so.) (Also, reimplemenations would need to do a lot of things that libdbus-1 does and those things are not really specced out yet - things like looking up the bus address in the X server (or similar on Win32, OS X), autospawning etc. comes to mind) Anyway, we should definitely leave space in GDBusConnectionClass (and GDBusMethodInvocationClass) for this so we can add an extension point later. David _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list