Hi Bastien, > > > > >> and I still have all the rights to do so. > > > > >> > > > > >> As long as we are still based on GLib, this will stay as it is. I am > > > > >> not > > > > >> jumping through any hoops, because David wouldn't respect prior art. > > > > > > > > > > How exactly would would have called a D-Bus implementation in GLib? > > > > > > > > Well you could have called godbus as that is more a gobject binding > > > > than a pure glib/GMainLoop one. > > > > > > GLib lives in a single tarball. It's only Marcel's hate for GObject and > > > the apparent need to be able to replace glib that spawned this thin > > > wrapper on top of libdbus you're using now. > > > > plain fact is that our gdbus code was there first. > > Nice comeback. > > > If you wanna turn this into a GObject discussion now, > > I don't. I'm merely pointing out that a file layout change might be a > good time to fix potential symbol clashes. > > > then please find a > > mailing list that cares. It is clearly not this one. > > I think you've made this abundantly clear. I don't think this attitude > is helping BlueZ thrive, when it's far less friction to fix problems > higher up in the stack. we will move away from GLib and libdbus (and also libnl) altogether at some point soon anyway. Then this discussion becomes mood. Our problems are the memory footprint and the abstractions done purely for making this run on Windows. With the embedded consumer electronics devices that we target this is creating more and more issues these days. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
