RE: Upstart Client Library
On Thu, 2008-06-12 at 13:54 -0700, Saravanan Shanmugham (sarvi) wrote: May be a different way to ask this question is would it make sense to have some of the header files associated with the message/errr definitions under the upstart directory LGPLed. This would make it simpler for people to write other forms of client libraries for communication with Upstart? You can use GPL libraries from GPL programs, the library does not need to be LGPL for you to be able to use it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
RE: Upstart Client Library
If I had a proprietary program and wanted to talk to Upstart. I believe I can only link a LGPLed client library into my application, correct? That library most likely has to share atleast header files with a piece of code in the GPLed Upstart Init code so that they share a common message structure and enum definitions. If those shared header files (shared between the GPLed Upstart Init and LPGLed Upstart Client library) are licensed under GPL, doesn't that contaminate the LPL licensing of the Client library? Sarvi -Original Message- From: Scott James Remnant [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2008 7:51 AM To: Saravanan Shanmugham (sarvi) Cc: Matthias Urlichs; upstart-devel@lists.ubuntu.com Subject: RE: Upstart Client Library Importance: High On Thu, 2008-06-12 at 13:54 -0700, Saravanan Shanmugham (sarvi) wrote: May be a different way to ask this question is would it make sense to have some of the header files associated with the message/errr definitions under the upstart directory LGPLed. This would make it simpler for people to write other forms of client libraries for communication with Upstart? You can use GPL libraries from GPL programs, the library does not need to be LGPL for you to be able to use it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
RE: Upstart Client Library
On Fri, 2008-06-13 at 08:20 -0700, Saravanan Shanmugham (sarvi) wrote: If I had a proprietary program and wanted to talk to Upstart. Licence your program under the GPL. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
Re: Upstart Client Library
2008/6/13 Saravanan Shanmugham (sarvi) [EMAIL PROTECTED]: If I had a proprietary program and wanted to talk to Upstart. I believe I can only link a LGPLed client library into my application, correct? That library most likely has to share atleast header files with a piece of code in the GPLed Upstart Init code so that they share a common message structure and enum definitions. If those shared header files (shared between the GPLed Upstart Init and LPGLed Upstart Client library) are licensed under GPL, doesn't that contaminate the LPL licensing of the Client library? The D-Bus library is dual licensed under the GPL | AFL 2.0 , which ttbomk allows it to be linked into proprietary, closed-sourced applications. Really, what your are trying to achieve is to re-invent libdbus. Michael Sarvi -Original Message- From: Scott James Remnant [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2008 7:51 AM To: Saravanan Shanmugham (sarvi) Cc: Matthias Urlichs; upstart-devel@lists.ubuntu.com Subject: RE: Upstart Client Library Importance: High On Thu, 2008-06-12 at 13:54 -0700, Saravanan Shanmugham (sarvi) wrote: May be a different way to ask this question is would it make sense to have some of the header files associated with the message/errr definitions under the upstart directory LGPLed. This would make it simpler for people to write other forms of client libraries for communication with Upstart? You can use GPL libraries from GPL programs, the library does not need to be LGPL for you to be able to use it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
Re: Upstart Client Library
On Wed, Jun 11, 2008 at 4:31 PM, Michael Biebl [EMAIL PROTECTED] wrote: 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 Michael (and crew), Is a prerelease of this version available in CVS/SVN/GIT/etc? Thanks, -Garrett -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
RE: Upstart Client Library
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: upstart-devel@lists.ubuntu.com 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 upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
RE: Upstart Client Library
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 -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
Re: Upstart Client Library
Matthias Urlichs wrote: Hi, Saravanan Shanmugham (sarvi): This sounds like Upstart is proposing a hard dependendency on D-Bus. It proposes a hard dependency on the d-bus library and protocol. (There needs to be *some* way of talking to init ... and the d-bus protocol seems to be reasonably sane for doing this kind of thing) talking to init can be accomplished without the overhead of dbus It does not propose a hard dependency on the system d-bus daemon. (That'd make no sense, as init needs to be controllable without any system services running; conversely, you might want to start dbus from the boot ramdisk before switching to the real init daemon.) If dbus is required for upstart, then the dbus daemon is better integrated _in_ upstart. smime.p7s Description: S/MIME Cryptographic Signature -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
Re: Upstart Client Library
Hi Matthias, This sounds like Upstart is proposing a hard dependendency on D-Bus. It proposes a hard dependency on the d-bus library and protocol. (There needs to be *some* way of talking to init ... and the d-bus protocol seems to be reasonably sane for doing this kind of thing) this would lead to a 1:1 connection and upstart maintaining its own D-Bus server. Not a good idea and a waste of resources. It does not propose a hard dependency on the system d-bus daemon. (That'd make no sense, as init needs to be controllable without any system services running; conversely, you might want to start dbus from the boot ramdisk before switching to the real init daemon.) I don't see a problem here since upstart is a process monitor. Its first job could be to start the system bus and make sure it keeps running. As simple as that. After that upstart can accepts commands over D-Bus like any other process. Actually I do have a different solution for that problem, but more on that later :) Regards Marcel -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
Upstart Client Library
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? Thanks, Sarvi -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
