comments on StatusNotifier spec

[Aaron J. Seigo]

On January 18, 2010, you wrote:
> On Mon, 2010-01-18 at 18:17 -0800, Aaron J. Seigo wrote:
> > 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.
> 
> No, you didn't. You declared that it didn't matter.

that is correct; i agreed with one point (ServiceRegistered) and not with 
another. to reiterate, the "Host" could be on another machine in the network 
for all the notifier item cares and it does "host" the item. there also hasn't 
been a compelling reason given for why "Host" in the name is so troublesome as 
to cause the spec to be changed in this manner. by contrast, ServiceRegistered 
not being a good name is a very sensible observation that probably does have 
enough weight to warrant a change.

personally, i'm a little confused as to why the term "Host" is controversial 
enough for us to be having this precise conversation. :) if there was no 
openness whatsoever to change, then i could understand. but there's a 
reasonable openness to change.

> > > , 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.
> 
> Right. But the point is valid and hasn't been addressed in the spec.

many of the issues raised haven't been addressed in the spec yet. the primary 
author of the spec (Marco) has been traveling since the start of this thread 
(not that others have been providing patches either :). right now we're 
gathering issues and they will get addressed in the spec; i actually spoke 
with Marco since this thread started about this very issue (getting issues 
with consensus merged into the spec). moreover, this is not the first round of 
input that has been offered and made its way into the spec. 

this may be the first time you or Dan have interacted with it, but this spec 
does already have a track record of accepting input in a reasonable manner. in 
fact, the requirement that the pixmap data be in network byte order was one 
such change.

so let's give it time, remain reasonable and try to concentrate on the issues 
rather than talk about talking about issues.

> > > 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.
> 
> It falls down for any use case.

that runs counter to the fact that we have a well functioning implementation 
of it that has been shipping for nearly 6 months and in fairly wide usage.

> How do you expect applications to use a service when the only
> description of the service is: "You can put a string here. The field is
> named 'Title', which should give you a rough idea what this is about.
> But we won't tell you if we translate it into morse code or signal it to
> the user via smoke signs.".
>
> It just doesn't work. 

that isn't a use case. that's using the generalization you already offered as 
a proof for the same. can you please provide real world use cases where this 
doesn't work in practice. because we have quite a few real world use cases 
that span a rather large set of behaviors that shows, quite demonstrably 
through the experience of shipping code to users, that runs counter to this.

these include sound volume, screen resolution, email and instant messaging 
notification, on disk file indexing processes, network management, clipboard 
server and many more. in each of these cases the application has been able to 
communicate, without regard for the resulting visualization, what information 
regarding its state that it needs to have delivered in the user interface.

on the host side, we now have two fairly different host implementations 
(though admittedly both are visually oriented) that shows how the flexibility 
on the visualization side can be used without problems to the applications.

these are real world use cases, and augmenting those with counter examples, 
even of the thought experiment sort (the audio "visualization" is one such 
though experiment), can be useful. the kind of hand waving and unrealistic 
examples we're trying to get by on in this discussion aren't exactly useful.

> Your defense against this argument so far has been
> that the examples are absurd

the solution to that is very simple: provide real world use cases where this 
won't work (or isn't working, as the case may be). by providing concrete 
issues to discuss we can have a concrete discussion.

> and that there will be some implicit
> understanding of what to expect 

honestly, i don't expect it to be implicit; that's why i'm engaging in this 
conversation, in fact. to help it become explicit.

> - what kind of a 'spec' is that, if all
> the semantics have to be read between the lines ?

the spec is clear (and will be clearer thanks in part to these kinds of 
discussions) on the mechanisms and the semantics of those mechanisms.

you are correct, in my opinion, that it doesn't delve much into the ideas (or, 
if you will, "philosophy") that drove the design. that has, actually, been 
covered in great detail on this list in the past with regards to this spec. 
evidently what this shows, however, is that we do need to put a section about 
the "why" of this spec. 

btw, do you know of any other fd.o specs that has such a thing? or do we have 
a history in fd.o of leaving out the 'why' and just documenting the 'what'? 
it's probably good to include the 'why', for the reasons we're seeing here. 
i'll try and make sure it's added to the spec. 

though honestly, i didn't think that splitting data and visualization was 
exactly a radical concept. evidently in the context of the system tray it is 
(at least currently), and so it should indeed by added to the text of the spec 
to help give more context to it.

> > 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.
> 
> Well, there was a call for the gnome side to 'sign off' on this spec a
> few days ago. That's what I meant by reaching consensus.

personally, i don't expect anyone to "sign off" on something they don't 
understand or are comfortable with. i'm completely ecstatic (no, seriously!) 
to see in depth discussions of specs happening. we really haven't been taking 
our specs seriously enough in the last few years and the results really speak 
for themselves (with some notable exceptions). at the same time, i think we 
need to undertake it with some reasonableness and rigor (such as providing use 
cases and/or clear lines of reasoning to augment the vague "i feel"s and 
rhetoric).

most of all, i certainly don't want anyone to feel time or social pressure 
into signing off on something. we have time (even if it can be awkward at 
times with regards to, e.g., release schedules) and we need to build a culture 
of openness here that has been rather lacking at times. so i support your (and 
Dan's) efforts here to provide a fine-tooth combing of the spec, 100%. in 
return, i think it's reasonable to expect that some of the things you turn up 
will end up being non-issues after they are examined. give, take, etc.

> > 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?
> 
> I think what you have so far may be a workable basis for an API, but as
> a specification it is not useful. Spec = API/Protocol + Semantics.

ok, so i think you completely missed what i was asking, which may be because i 
asked it poorly? i was asking if you think it's worthwhile to have a 
discussion based on the idea that we have a mutual goal of consensus. (i hope 
you do.) i didn't ask if we had consensus yet, as it's plainly obvious we 
don't. yet. :)

now, if you wish to discuss the usefulness of a specification i could point to 
any number of fd.o specs that similarly fail your requirements fairly 
spectacularly.

i'm also not 100% sure what you are thinking when you say "Semantics". i can 
think of a couple different meanings of that word in the context of this 
particular spec (e.g. do you mean "defining what the visualization must do 
with certain pieces of the published information" or do you mean "defining the 
design goals of the spec better" or ...?)

if you could be a bit more clear on what you are looking for when you say 
"Semantics" then i can (hopefully :) reply in kind.

-- 
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