Notification spec issue: Ability to assign an icon *and* an image to a notification
Aaron J. Seigo
aseigo at kde.org
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 kde.org> 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 freedesktop.org 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
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090624/91874cc8/attachment.pgp
More information about the xdg