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