Managed D-Bus 0.3
alp at atoker.com
Fri Dec 15 03:36:48 PST 2006
Havoc Pennington wrote:
> Alp Toker wrote:
>> If the spec were maintained in its own repository like every other
>> spec on freedesktop.org, it would be much easier for other D-Bus
>> implementations to contribute to it,
> How is that? You are just talking about saving some disk space in your
> checkout of the spec?
I don't see what disk space has to do with anything. I would prefer to
contribute to a spec that is maintained outside of the competing
implementation's repository in the same way that I deal with other
freedesktop.org specifications, but if that isn't the way you want to do
things, I can live with that.
>> as well as giving them some reassurance that they won't be relegated
>> to second class when it comes to working on protocol enhancements.
> Realistically, other implementations *are* a little bit second class, at
> least right now. The spec is pretty incomplete and the reference
> implementation is thus required as a way to know what the behavior is
> intended to be. Also, we are unlikely to change the spec in ways that
> break the reference implementation's ABI guarantees.
I can't really tell my users that they are using a "second class"
implementation. You are welcome to hold that opinion.
> I certainly welcome proposed protocol enhancements (in fact I'd very
> much want to see such proposals), and we could even include "optional
> features" in the spec that the reference implementation does not have.
> The most important thing for making other implementations work well,
> imo, is an implementation-independent test suite (ideally including an
> interoperability testing framework)
I look forward to working together on new features and test suites.
There's no doubt that D-Bus is helping developers put out better
applications, and that's all that matters.
>> I wasn't planning on bringing up this issue, but it has to be
>> mentioned now that you're asking me to submit patches :-)
> I was just saying "if someone is writing docs for you anyway, they may
> as well do it in the form of spec patches"
> If nobody is writing docs for you and you're "reverse engineering" (so
> to speak), then spec patches would be extra work, so it's up to you.
> btw, I doubt you need to be rigorously clean room here as I understand
> it. Clean room is more about making it easy to *prove* you aren't a
> derived work than it is about actually *not being* a derived work, in
> other words as long as you just refer to what the dbus reference code
> does rather than basing your code on the dbus reference code, you could
> AIUI look at the reference code. Which would probably help make the two
> implementations more interoperable.
> Also, the worst case if a court declares your implementation a derived
> work is that you have to license those portions deemed to be derived
> under the AFL, which is virtually identical to the MIT license anyhow in
> practical effect.
I am doing a a clean room implementation to provide validation for your
design and specification, not because I think your code is tainted.
Maybe you missed this point.
More information about the dbus