On January 18, 2010, Matthias Clasen wrote: > The spec is full of awkward > naming (StatusNotifierHost, ServiceRegistered, etc),
as noted in my replies, i agree that ServiceRegistered should/could be named better. the quibble on StatusNotifierHost was whether "Host" implies it is a remote system on the network or not, and i addressed that in my reply as well. > internally > inconsistent (e.g there's a ProtocolVersion property, but the document > has no version information that I can find) yes, that is indeed missing. something to add to the spec. > , ignores decades old lessons > from X (when you pass on events, _always_ include the timestamp), i believe that was covered in another thread, and i don't think there was much in the way of debate there. > and it > is entirely void of expected behaviors for either side of this > protocol. that is intentional, for the reasons i've described. if you can provide concrete use cases for which it falls down, then that would be great. > But instead of addressing these criticisms, you seem to be only > interested in selling your abstraction layer philosophy. only when it comes to issues that touch on the idea of creating a division between the data and the visualization (which is not, of course, an abstraction layer at all but an interface, one which we hope to make well defined). now, there are two really interesting things about this discussion and your email within that discussion, imho: * very few of the fd.o specs (or hopeful fd.o specs) that emerged after the first generation of them have gone through much rigorous discussion and vetting; i'm glad we're able to do that with this spec as it's really the path we need to be on for specs. it's easier to simply not discuss them and just throw things out there, and some of the specs we have today have suffered greatly as a result. i'm happy to see this spec getting attention and getting input for improvement. * you have (unfortunately) decided to focus on the points where there is a difference in viewpoint and skipped over where there was consensus. you therefore painted a rather bleak picture which really isn't the case here at all. where there is disagreement, i've taken the time to explain _why_ there is and at certain points have asked for _further input_ such as concrete use cases so that we can continue the discussion productively towards a meeting of the minds. where there is agreement, such as on your point about the protocol version description missing, i've also noted my agreement explicitly as that's also important to keeping things moving. we won't always agree immediately, we won't always be right (that goes in both directions in this conversation. that's the nature of collaboration. > Not a good sign for reaching a consensus. if by "consensus" you mean "immediately agreeing with everything someone else says" then, yes, it's not a great sign. thankfully, that's not the goal here at all. if by "consensus" you mean "striving to arrive at common ground through open discussion leading to agreement and/or compromise" then i think we're doing fine. i'm glad you pointed out the issue with the protocol version missing. that's useful and beneficial and when added the spec will be that much better for it. if we can try and keep the discussion focused on such issues that need addressing, rather than diverging off into meta-discussions about how much person A agrees or not with person B's every word, we'll continue to make reasonable progress. note that i do not expect Dan or you to agree with everything i say, either. i am, however, open to and looking forward to continued discussion about the points we don't have shared ground on until we reach a point that we do. what do you think? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
