Upstart Client Library

[Saravanan Shanmugham (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.

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:mbiebl at gmail.com] 
>Sent: Wednesday, June 11, 2008 4:32 PM
>To: Saravanan Shanmugham (sarvi)
>Cc: upstart-devel at lists.ubuntu.com
>Subject: Re: Upstart Client Library
>Importance: High
>
>2008/6/12 Saravanan Shanmugham (sarvi) <sarvi at cisco.com>:
>>
>> 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?
>