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

[Brian J. Tarricone]

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 
process, or is a simple series of "My name is Foo and I represent Bar 
and I approve of this spec" in a list somewhere sufficient[1]?  Then 
potential spec users can say "I can implement this spec, and it should 
work with apps on any desktop," or at the very least can easily 
acknowledge, "well, I can implement this spec, but there may be interop 
problems on desktop XYZ," and at least make an informed decision.

	-brian

[1] Of course then there's the question of what "qualifies" Foo to 
represent Bar, which can be difficult with large decentralised OSS projects.