Clarification on upstart-0.5 and dbus usage

[Saravanan Shanmugham (sarvi)]

>-----Original Message-----
>From: Scott James Remnant [mailto:scott at netsplit.com] 
>Sent: Wednesday, June 18, 2008 5:48 PM
>To: Saravanan Shanmugham (sarvi)
>Cc: Garrett Cooper; Michael Biebl; 
>upstart-devel at lists.ubuntu.com; Casey Dahlin
>Subject: RE: Clarification on upstart-0.5 and dbus usage
>Importance: High
>
>On Wed, 2008-06-18 at 17:36 -0700, Saravanan Shanmugham (sarvi) wrote:
>
>> 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.

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.

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.  

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?

Sarvi
  

>
>The D-Bus protocol has been frozen for over eighteen months, 
>and the reference implementation has been stable for an 
>equivalent length of time.
>
>It is in daily use, a dependency of the GNOME and KDE desktop 
>environments, and a building block of many other 
>freedesktop.org specifications, protocols and services -- most 
>notably HAL, the Hardware Abstraction Layer.
>
>
>The only other relevant communication frameworks which boast 
>this stability are CORBA, which is rather more heavy weight 
>than D-Bus, and DCOP which D-Bus was designed to replace.
>
>
>You repeatedly state that D-Bus is not suitable, yet you are 
>not stating _why_ D-Bus is not suitable, and not suggesting 
>any better alternative.
>It is therefore very difficult for me to judge the merit of 
>your proposal.
>
>> If my team were to comeup with a modular compile-time plugable 
>> interface between Upstart and D-Bus, would something like 
>Glib Object 
>> system be a good way to do that. If I understand right, D-Bus works 
>> Glib Objects and Glib Object system can be made to work with other 
>> messaging mechanisms as well.
>> 
>Upstart does not use GLib.
>
>The only real way to do it would be to develop an API and 
>behaviour compatible libdbus replacement for your chosen 
>messaging system.  Since that would have to also behave like 
>D-Bus (including objects, properties, introspection, etc.) it 
>would be a lot of work.
>
>In fact, such a layer would be roughly the same size as D-Bus, 
>if not larger.
>
>So why not just use D-Bus?
>
>Scott
>--
>Have you ever, ever felt like this?
>Had strange things happen?  Are you going round the twist?
>