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.
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? And we would be glad to contribute to this effort. Sarvi >-----Original Message----- >From: Michael Biebl [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 11, 2008 4:32 PM >To: Saravanan Shanmugham (sarvi) >Cc: [email protected] >Subject: Re: Upstart Client Library >Importance: High > >2008/6/12 Saravanan Shanmugham (sarvi) <[EMAIL PROTECTED]>: >> >> Hi, >> As Garret Cooper mentioned earlier, my team at Cisco >is thinking >> of working with Upstart as a process manager. >> >> One of the questions that have come up with respect to a client >> library to control Upstart. >> >> There is a need for a process to talk/listen to the UpstartInit >> process for the following >> 1. Notifications about the state of a process. >> 2. Request Upstart to read a new/update job file. >> 3. Send an event to Upstart to trigger the start of a job. >> >> The above functions are part of the upstartctl command, but >need to be >> in a library form that can be linked into another >application so that >> it can interact with Upstart. >> >> Now it should be relative;y simply to create client library >with some >> well defined API, and for the most part this already seems to be >> available in the form of message definitions in the upstart >directory. >> >> But they are in GPLv2 licensing. I would suspect such a >client library >> that could be linked to many 3rd party applications needs to >be LGPLed >> instead of GPLed? >> >> What are our options here? >> We could write/release our own LGPLed client library that talkes >> to UpstartInit but that would still need to share some header files >> and stuff relating to message definitions, error numbers, etc. or >> duplicating them and trying to keep them in sync. >> Are there better options? > >I'd say, wait for 0.5 and use the D-Bus interface. > >Cheers, >Michael > >-- >Why is it that all of the instruments seeking intelligent life >in the universe are pointed away from Earth? > -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
