Hi Sarvi, > >> And I completely support that effort. > >> > >> Its high time we stepped up a layer from plain Unix domain > >sockets and > >> talked a higher level API. And I agree D-Bus is very likely the > >> equivalent 'Unix Domain Sockets' for this purpose. But unfortunatley > >> its not there yet. All this means is that D-Bus needs some more time > >> to mature as a spec and as an implementation to reach that status. > >> > >I am unsure on what you are basing this statement. > > Sarvi>> The fact that I still find embedded linux distributions without > D-Bus. But they all have sockets. > But then I am not trying to argue against D-BUS as a mechanism for the > future of Upstart at all. > But merely pointing out that there are tonnes of small embedded systems > out there with their own already chosen communication infrastructure > that will want to continue to use their own. The cost of moving to D-Bus > for these system may be prohibitive due to a large existing code basees > that may be dependent on their existing communication infrastructure. > > And 90K lines of code (which is the current size of D-Bus) is a high > price to pay in these systems just for the sake of talking to Upstart. > While Upstart itself is just half the size of D-Bus.
as Scott pointed out, you always need a protocol to talk over sockets. If you go down to the D-Bus website and read the D-Bus specification then you will see in its basics D-Bus is only that. And the D-Bus bus daemon and the low-level library are only reference implementations of this protocol specification. If you want, you can talk D-Bus directly. I mentioned that before, the Mono and Java bindings do exactly that. They open the D-Bus transport and speak the D-Bus protocol. And this is what I mean by optimizations for D-Bus. If you think that the reference implementation is not good enough for you cases, improve it. Not waste your time to invent yet another IPC protocol. Besides that, the reference implementation contains code for making D-Bus run on Windows, MacOS X and every other Unix. If you would go ahead and do a more Linux centric implementation than you will see it would be much smaller. > And I don't believe I ever claimed in any of my emails that D-Bus is not > suited for this purpose. Quite to the contrary, I have said Upstart > should continue to support D-Bus. But I do feel that we can't always > presume that D-Bus is ubiquituous enough that it will always be > available in any embedded system. And so in that context I am merely > stating if Upstart is to be perceived as embedded friendly, we should > allow alternates to D-Bus to exist or be implemented. Please see my point above. D-Bus is a protocol specification and that is perfectly fine and really well defined. If you are not happy with the current implementation of D-Bus, please fix the implementation and not just invent another IPC and please don't bother Upstart with it talking a second protocol. > Case in point for the above, is Cisco. We have many a linux based > embedded platforms. They would all benefit from a well featured process > manager such as Upstart. But we find ourselves not being able to move to > D-Bus, because these existing platforms already have some messaging > infrastructure already and moving all of these to D-Bus is not always > viable or cost effective. This has nothing to do with whether D-Bus is > suited for our purpose. And I bet we are not alone here. You don't have to move them all at once. Create a small D-Bus proxy in the beginning and then slowly start moving your services over to use D-Bus. If you wanna use open source software, you will see that almost every maintainer will point you to D-Bus, because during the last three years it became the defacto IPC within all programs. > Marcel, seems to think that just by allowing the implementation of > alternatives to D-Bus in Upstart would cause bloating in Upstart. I find > that argument without merit. There is a bunch of functions in nih/dbus.c > which essentially define the D-Bus communication into Upstart. The rest > of upstart don't seem to have much that is really D-Bus specific. So as > long we as we continue to keep the D-Bus specific stuff to the > nih/dbus.c files i.e. outside of the main upstart code, people could > implement alternatives to nih/dbus.c and use the Makefile to decide > which one gets compiled in. Why would this bloat Upstart? That won't work. Looks like a good idea, but in the end doesn't work. I have been there and tried it. This is nearly impossible to maintain and create a complex abstraction. It will bloat your code. If you don't believe me, that is perfectly fine. I am not going to stop you from doing it, but I did warn you :) Regards Marcel -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
