comments on StatusNotifier spec
Aaron J. Seigo
aseigo at kde.org
Mon Jan 18 18:17:47 PST 2010
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.
> 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
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
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
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
More information about the xdg