Upstart Client Library

[Marcel Holtmann]

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