Managed D-Bus 0.3
Havoc Pennington
hp at redhat.com
Thu Dec 14 08:41:30 PST 2006
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
More information about the dbus
mailing list