Upstart Client Library

[Saravanan Shanmugham (sarvi)]

May be I need to explain myself better. 

I have nothing against D-Bus as a communication mechanism or whether it
is suited for embedded systems. 
I am not questioning if suitable for communicating to/from Upstart, but
wondering if it is reasonable to say that's the ONLY way to talk to
Upstart. Specially since Upstart is porposing to play such an important
role in the system.

It doesn't seem reasonable to expect that all embedded systems to use
D-Bus.

Upstart and its feature set is great and is going in the right
direction. 

All I am suggesting is that Upstart should be fuly usable independent of
the communication mechanism that platform chooses to use.

Sarvi

   

>-----Original Message-----
>From: Marcel Holtmann [mailto:marcel at holtmann.org] 
>Sent: Thursday, June 12, 2008 12:42 PM
>To: Saravanan Shanmugham (sarvi)
>Cc: Michael Biebl; upstart-devel at lists.ubuntu.com
>Subject: RE: Upstart Client Library
>Importance: High
>
>Hi Sarvi,
>
>> This sounds like Upstart is proposing a hard dependendency on D-Bus. 
>> Is this really necessary. Has the impact on small/embedded platforms 
>> been considered.
>
>please lets not have this discussion again. D-Bus is perfectly 
>fine for embedded systems. Actually having more than one IPC 
>is the part that is a problem for embedded systems.
>
>> Communication infrastructure is a key design choice for any embedded 
>> platform, hence it is important that a platform developer have the 
>> flexibility to choose which one he can use on his platform. And 
>> embedded developers don't have the flexibility to suport multiple 
>> alternatives to solve the same problem, say communication.
>> 
>> If Upstart is to be the future replacement for the SysV Init 
>process, 
>> embedded platform developers should be able to use Upstart 
>instead of 
>> sysV Init without being forced to use D-Bus or any particular 
>> communication mechanism on their platform.
>> 
>> Would it be possible to keep this part modular with well defined API 
>> so that we can plug into different communication mechanisms?
>
>That is simply plain non-sense. D-Bus is perfectly capable of 
>handling this and is well established and has minimal 
>dependencies. No need to invent any kind of abstraction or 
>just another IPC.
>
>So if you don't like the D-Bus library (which is fine), then 
>talk the native D-Bus protocol directly. However that is up to 
>your client or the binding that your client is using. Last 
>time I check, the bindings for Mono and Java are not using 
>libdbus and instead talking D-Bus directly.
>
>I would not advise this for upstart right now, but in theory, 
>it could do exactly that. Talking directly to the system bus 
>without getting libdbus involved is perfectly fine and valid.
>
>If the D-Bus system bus is a problem for you, then it is time 
>to optimize this and people have talked about it. I have my 
>own plans to get the bus part into a better shape. Look out 
>for announcements. I should be done with it soon.
>
>Regards
>
>Marcel
>
>
>