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. _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
