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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
