Managed D-Bus 0.3

[Alp Toker]

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.