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

[Aaron J. Seigo]

On Thursday 25 June 2009, Brian J. Tarricone wrote:
> On 06/25/2009 01:27 PM, Aaron J. Seigo wrote:
> > On Thursday 25 June 2009, Brian J. Tarricone wrote:
> >> Thank you -- that's exactly how I feel like this conversation is going.
> >>    As a notifications daemon implementer, I *really* don't appreciate
> >> being told "hey, just because we're pissed off that this wasn't
> >> standardised in the 'proper' way, you have to change how your app works
> >> and make a new release, otherwise you won't be compatible with apps
> >> going forward."  That's a dick move.
> >
> > Brian, while I don't appreciate the tone of your email here (and feel it
> > borders on offensive), I'm glad that you're at least expressing your
> > opinion. I'd ask, however, that you do not rewrite history: we have been
> > raising these issues about galago for years here on this list as well as
> > directly with the authors. i understand that it's convenient for you to
> > ignore that, but the annoying situation you're in is your own making at
> > this point.
>
> Sorry, but I wasn't involved in the Galago project, and, unless my
> memory is off, I wasn't involved with fd.o back when Galago came about.
>
> If you're saying that the situation I'm in is of my own making because I
> found galago-project.org, saw that it used the org.freedesktop
> namespace, and saw that people were using notification-daemon and
> libnotify on the desktop and thought it was useful enough to write an
> implementation of it, then... sure, that situation is of my own making
> and is certainly my "fault."
>
> If you're trying to suggest that I was a part of the initial
> standardisation non-process and I'm responsible for hijacking the fd.o
> namespace, then that couldn't be farther from the truth.
>
> > I'd also hope that you would value the working nature of fd.o as a
> > collaboration point for F/OSS projects, and as such start engaging in a
> > process of "how do we fix this" instead of continuing to argue something
> > that will not actually lead to significant improvement.
>
> Yes, I'm getting the feeling that this thread is a dead end.  I intended
> perhaps 2 emails on the subject, but clearly it's gone farther than that.
>
> I love maintaining backwards compat when possible.  I hate rewriting
> things.  I hate throwing away code that works.  And while yes, it does
> have flaws, current o.fd.Notifications code does work.  It would be nice
> to keep that working when we move forward.
>
> But I don't just mean that in the sense that we can support both
> interfaces at the same time.  If we add a completely new interface and
> clients start using it, presumably they won't be using the old interface
> anymore.  So daemon implementations that haven't implemented the new
> interface yet just don't display notifications from those clients
> anymore at all, rather than displaying notifications that are
> potentially degraded.
>
> > now, you don't want to see any change in org.freedesktop.Notifications.
> > i'm willing to accept that, and if that is what happens it will mark the
> > end of my involvement with and support of the current freedesktop.org[1]
> > _unless_ we as a group can come up with a way of ensuring to our
> > consensual satisfaction that fd.o will no longer be run this way and
> > thereby avoid creating more poor results.
>
> I don't want to see *incompatible* changes if they aren't necessary.  If
> you can achieve what you want by making compatible extensions to the
> interface, that's fine.  If you can't, and you really have to change the
> API of the current interface, then yes, absolutely it should be renamed.
>   My objection is more to changing the name with no corresponding need
> to from an API-compat perspective.  If that isn't what's going on, I
> apologise, but that's what Aurelien suggested was happening in the email
> I originally replied to.
>
> > this is a vote of no confidence in fd.o as it stands, and the cause of
> > that lack of confidence is galago in how it represents the broken / lack
> > of processes here.
> >
> > start arguing about that and we'll get somewhere.
>
> Well, I don't have much to argue about that.  I'd agree that fd.o
> suffers from lack of consensus and participation from all desktops (and
> even if we had great participation from GNOME, KDE, Xfce, and LXDE,
> maybe that even wouldn't be enough, since we're not the entire world).
>
> But I don't really know how to fix that.  You mentioned elsewhere about
> being able to track and record consensus -- I think that's important.
> What tools exist to do that?  Is it necessary that it be a very formal

at the moment, we have no official tools. my proposal has been this:

* we have all the specs, agreed on, drafts, crap, etc. hosted in a common 
repository (e.g. a git repo). all work on them goes on in that repository and 
nobody has to ask for permission to add a new spec, or fork the repository and 
work on changes / improvements / additions to existing specs

* specs would have maintainers who are charged with providing oversight; when 
they disappear (it happens in F/OSS as we all know :) then we find a 
replacement

* drafts/changes are accepted into the spec using simple consensus (e.g. based 
on discussion on this list or elsewhere involving the stakeholders) combined 
with "maintainer has the tie breaker vote" sort of mechanism

* projects that implement the spec record that they do so (along with which 
version(s) of their software include support for which version(s) of teh spc) 
alongside the specification itself in the repository itself in an xml file. 
projects can also record a lack of intention to implement or support a given 
spec.

* determining the consensual support for a spec then becomes a simple task of 
tallying up projects that are users of, passed on or just not taken up a 
position on a given spec

once a certain threshold is passed[1] then it gets flagged (something that can 
be done automatically, even) as an "fd.o accepted specification" and then gets 
further privileges like use of org.freedesktop on the dbus.

this wouldn't be much overhead at all, the new bits can be nearly all 
automated (and i'm willing to write those bits), the results can easily be 
pushed to a website or referred to by third parties looking to implement 
interesting specs, actually _lowers_ the barrier to entry and creates a "paper 
trail" for it all.

i actually started an experimental git repo for this on gitorious.org, and 
half a dozen or so people have working copies of it.

i think such a system would alleviate the bulk of future issues without 
bogging us down in bureaucracy.

[1] what that is needs some discussion, but shouldn't be too difficult to 
arrive at; perhaps sth like "KDE and GNOME, or one of those plus a % of the 
other projects involved, or all the other non-KDE/GNOME projects")

-- 
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 : http://lists.freedesktop.org/archives/xdg/attachments/20090625/1ba3963b/attachment.pgp