Clarification on upstart-0.5 and dbus usage

[Garrett Cooper]

On Wed, Jun 18, 2008 at 6:29 PM, Marcel Holtmann <marcel at holtmann.org> wrote:
> Hi Sarvi,
>
>> >> 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.
>> >
>> >I think that Scott and I explained that this would only
>> >increase complexity inside Upstart and that this makes
>> >basically no sense. We don't need support for two IPC
>> >mechanism. We use D-Bus.
>> >
>> >And if D-Bus looks like such a problem to you, then even
>> >Upstart might not be the right solution for you.
>>
>> Sarvi> Are you implying that if my team was willing to put the effort
>> into making Upstart more suitable for Embedded systems as well, that it
>> would be contradictory to the direction/goals of Upstart. Is the
>> intention of Upstart only big heavy Workstations.  Note that LaunchD the
>> Apple equivalent of Upstart runs on the iPhone as well, and I don't see
>> why Upstart needs to aim any lower.
>>
>> To tie the destiny of Upstart to D-Bus does not seem to be in the best
>> interest of Upstart.
>
> it actually is and I have made that point already. So has Scott. If you
> wanna put effort into adding an extra IPC layer and thus also an IPC
> abstraction into Upstart, you gonna bloat Upstart and make it only more
> complex. This is not helping. It is really not.
>
> I had all these discussion before and have heard it all, but start
> looking into D-Bus and start using it. Don't waste time and resources
> into adding something to Upstart. Use the manpower to make D-Bus better
> and more suitable for embedded if that is needed. Personally, I don't
> see that since systems like Maemo, OpenMoko, Android, ALP and many more
> are using D-Bus successfully in its current form.
>
> For some reason everybody thinks that D-Bus is bloated, but it is not.
> The low-level part is a well defined communication protocol and a
> message bus. It is not CORBA or some crazy stuff like DCOP or something.
> It is small and well suited for embedded.
>
> Nobody is stopping you from trying to add another IPC to Upstart, but
> the success of this idea is really questionable and once you use D-Bus
> for any second component in your system, this effort becomes useless and
> it bloats your system. So trust me when we all say that you should
> accept D-Bus as way of talking to Upstart and roll with it. You will see
> the benefits really quickly.

Wow, this discussion evolved quite a bit from what I originally intended.

Uhm, let's just put it this way:

There is a large concern are over licensing, w.r.t. exposing some IPC
shims / API's for Cisco components not yet AOK'ed for public release.
So, in order to cut through the red tape we're doing our best to move
around the situation to a neutral / positive position where the
lawyers are happy and Cisco won't be liable for breaking any licensing
agreements in source code.

The AFL License D-Bus is dually licensed under isn't a part of the
accepted licenses yet, even though the language is new BSD
License-like; we're waiting a reply from Cisco Legal on whether or not
we can proceed with including D-Bus as the necessary shim between
upstart and our proprietary components.

I'm not entirely sure what's missing from D-Bus that we would need to
replace with our own proprietary equivalent, and I'll need to sync up
with Sarvi on that point because he knows the status quo from the
Cisco-side much better than I do.

Thanks for the explanation(s) though. Time to go read the source /
specs for D-Bus and dive into upstart's source a bit further.

Take care,
-Garrett