Reading Bryan Clark’s blog and then back to Rodrigo’s blog and finally coming back to the Spec itself. I can’t help but think that we are going down a dangerous road that if adopted by the Gnome developer community without some forethought could lead to a total train reck.

A bit of back-story

You see I am a huge advocate of interoperability where it makes sense. One of the best ways to get there is to define a specification that everyone (or at least the majority) agrees upon. Why is it then that I find myself fighting specifications lately? It seems that writing specifications is the new in thing to do with terms like “generic solution” and “unification”, but without a solid engineering basis these specs often become bloated and unfocused. The problem is it is easy to dream up a super awesome cool system that solves the worlds problems. Engineering it so it is useful is another story altogether. Generally the more complex the spec, the less use anyone is going to get out of it (and the less compliant implementations will be).

Back to desktop notification

Now I am not saying the desktop notification spec is that bad. I have seen far worse specs. The desktop notification spec is written up by some smart guys and it has a good basis to work on. It does have a defined problem it is solving, all be it not as focused as I would like to see.

It grows larger by the day and I don’t want to see it go down the road of bloat that other specs have. I mean come on, a notification on how much trash you have? I just dumped my trash. I don’t need to be told what I just did. Or weather changes? Having a notification popup every time the weather changes a slight bit is just silly - “Oh by the way it is sunny out so you can go outside and ignore every other annoying message I will throw up on your desktop”. To be fair Rodrigo was most likely just playing around with the code and none of that would actually get into the desktop proper.

If we are serious about getting these notifications into GNOME we need to step back, take a breather and set some constraints on what it means to be a notification. What services do we really want to use the system for? How do users interact with these notifications? How can we pare down the spec in relation to these constraints? Remember it is easier to add to a spec once it has been agreed upon than take away from it.

I think Bryan has the right idea. Pick a few apps and write notifications for them. Once we have defined what is actually needed we can then tack down only those parts of the specs that were used. As our needs grow we can add more definition. This way we will be able to keep on the right track, make it easier for others to adopt and not end up where so many other over engineered specs have gone to die.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]