comments on StatusNotifier spec

[Matthias Clasen]

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. 


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


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

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. Your defense against this argument so far has been
that the examples are absurd and that there will be some implicit
understanding of what to expect - what kind of a 'spec' is that, if all
the semantics have to be read between the lines ?

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

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