Notification spec issue: Ability to assign an icon *and* an image to a notification

Aaron J. Seigo aseigo at
Wed Jun 24 13:23:36 PDT 2009

On Wednesday 24 June 2009, you wrote:
> On Wed, Jun 24, 2009 at 5:59 PM, Aaron J. Seigo<aseigo at> wrote:
> > org.freedesktop.Notifications ... *sigh* sorry, but that's not
> > acceptable.
> >
> > calling these "Notifications" is incorrect and will block future use of
> > that name for a proper notification spec. it was a mistake for whoever
> > decided it was a good idea to grab an org.freedesktop prefix in the first
> > place without first establishing it as a accepted and
> > used system, and i don't think we need to reward that behavior at the
> > cost of the platform.
> What's wrong with keeping the current fd.o prefix if implementations
> are compatile?

what "wrong" is that fd.o is a shared namespace. you can experiment within 
your own namespace all you want. using org.freedesktop means something, or at 
least should mean something, pretty specific: this is something we have 
consensus on and third parties can rely on it being use as such. when we 
simply play dog-pile-on-the-dbus, it creates a very uncomfortable situation 
where projects are faced with inconveniencing third parties or adopting 
technologies that do not fit their needs at all. worse yet, it creates races 
where one group will race to get their library pushed out with an interface on 
org.freedesktop, creating barriers to others working on similar things.

it's a sub-standard and unnecessary mode of operation.

before something hits org.freedesktop, it _needs_ input from and consensus on 
by all parties who share that resource.

Example: i think the new system tray dbus spec we've drafted up is pretty damn 
good. others we've showed it to in different projects are pretty happy with it 
as it's shaped up as well. we are, however, keeping it under the org.kde 
umbrella until such time as we (or someone else, if they wish to move it 
faster) presents the spec here and there is consensus. we're still working on 
ensuring it's a good system (part of Plasma's 4.3 requirements), and didn't 
want to inflict it prematurely on org.freeesktop. 

that's a demonstration of respect for the shared resource, and respect for the 
choices of other projects. for all i know, perhaps gnome will have no interest 
in implementing a d-bus driven system tray. so be it. i would not try and 
presume until gnome has had a chance to review and provide input.

a draft spec is in progress, and you can find it on gitorious here:

that, at least to me, is a sensible and fair way to go about collaboration 
without getting bogged down in W3C-like specification ratholes. it's also not 
free wheeling cowboy antics where we just throw things on the bus willy-nilly.

> This is XDG, where we agree upon things that we need to use in the
> real world, not W3C where other nice guys wonder what people might be
> doing in ten years from now. A "de facto standard" is better then a
> perfect specification with no implementations.

yes, that's fine; however, we can create implementations and work towards them 
becoming true shared standards, through practical measure and effort, and 
_then_ move them into a shared namespace. otherwise it becomes a gold rush 
land grab with no clear communication, coordination or coherence for the two 
primary audiences that benefit from this effort:

* our users

* third party developers

as well as the primary stakeholders: each other.

> Just make it clear that the API is subject to changes in the future
> until we all agree that Notifications are 1.0-stable.

i really don't think that's what happened here. :)

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 Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : 

More information about the xdg mailing list