[Mono-list] Managed D-Bus 0.3

[Havoc Pennington]

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?

> 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 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 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.

Havoc