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.
Until then people will want other ways to talk to Upstart, than D-Bus, for various reasons. Code Size, integratiion with existing communication infrastructure, etc. 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. Any other better ways of doing this? Thx, Sarvi >-----Original Message----- >From: Scott James Remnant [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 18, 2008 5:16 PM >To: Saravanan Shanmugham (sarvi) >Cc: Garrett Cooper; Michael Biebl; >[email protected]; Casey Dahlin >Subject: RE: Clarification on upstart-0.5 and dbus usage >Importance: High > >On Wed, 2008-06-18 at 17:04 -0700, Saravanan Shanmugham (sarvi) wrote: > >> But that said, D-Bus is a fine choice for now. I hope though, the >> Upstart community is open to code contributions from us that >allow for >> modular alternatives to D-Bus. Ofcourse without compromising on >> performance or clean code. >> >Would the effort not be better spend fixing whatever >problem(s) you have with D-Bus? > >It really has become the standard communication mechanism for >Linux, and would greatly benefit from an embedded eye. > >Scott >-- >Have you ever, ever felt like this? >Had strange things happen? Are you going round the twist? > -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
