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

[Brian J. Tarricone]

On 06/25/2009 03:22 AM, Patryk Zawadzki wrote:
> On Wed, Jun 24, 2009 at 10:23 PM, Aaron J. Seigo<aseigo at kde.org>  wrote:
>> On Wednesday 24 June 2009, you wrote:
>>> 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.
>
> Sure, this would all be valid had you reported these issues 5 years
> ago. Undoing the bad deed now actually is more evil than leaving
> things as they are. We'd be breaking 5 years worth of software just
> because we feel obliged to punish *someone*.

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.

Perhaps I took a "risk" by implementing something that isn't a 
community-blessed standard (apparently; I thought most people were happy 
with it since it's been around some time without any new complaints that 
I heard), but telling me that it's my own damn fault doesn't make me 
feel particularly inclined to redo some of my work to support a new spec.

For what it's worth, given the issues, history, and objections raised by 
Aaron, I *do* agree (taking his POV at face value, anyway) that the 
original spec was introduced and de-facto standardised without an 
appropriate level of consensus.  That's a shame, but it's done, and 
can't be undone.  "Punishing" people for that now is just childish.

If you're making incompatible changes that have to be done, and can't be 
done in a compatible way, fine... change the name of the interface.  But 
if the interface is semantically and API compatible with the old, 
changing the name is useless make-work that frankly just pisses me off.

	-brian