comments on StatusNotifier spec

[Aaron J. Seigo]

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