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

[Brian J. Tarricone]

On 06/25/2009 12:11 PM, Jeff Mitchell wrote:
> Brian J. Tarricone wrote:
>>> The question is what's more important to you: is it backwards compatibility,
>>> or is it equal treatment for all parties with all the community implications?
>> Backwards-compat, definitely.  I'm sorry, but grow up.  We live in a
>> world where things don't always work out as they should.
>
> By this logic, you should be using Windows.  Microsoft takes on huge
> burdens to maintain backwards compatibility (see an interesting blog
> called The Old New Thing).  Sure, it's not the best OS out there, but
> things don't always work out as they should.

There should be a form of Godwin's Law that describes how arguments can 
devolve into "well then you should just use Windows."

>>> If keeping backwards compatibility will cause certain developers to reduce
>>> future cooperation and standardization efforts (as Aaron indicated), I wonder
>>> if it's more important than breaking stuff but going forward with mutual goals.
 >>
>> If those certain developers can't handle not getting their way, then,
>> frankly, I don't particularly care what they do or don't do.
>
> Again, you boil this discussion down to dishonest simplicities.

I really resent being called dishonest when I am presenting my arguments 
as honestly as I know how.  If I am arguing from a flawed premise or 
based on incorrect information, please point out where and how I've made 
a mistake, and I'll apologise, but I don't believe that's the case.

>  The
> problem is not certain developers not getting their way, the problem is
> the ineffectiveness of fd.o at reaching community consensus, agreeing on
> standards, and enforcing them (in whatever manner possible or appropriate).

How are those two things different?  Emotionally, they are, but 
semantically and practically, they're the same thing.

> If fd.o has no ability to actually foster cross-platform,
> cross-environment, cross-application, and/or cross-library
> communication, then it brings up the question: what's the point?

Agreed.  But "fixing things" doesn't necessarily mean throwing away the 
-- imperfect by not worthless -- things that already exist.

> fd.o is supposed to help create community-derived standards, not serve
> as a dumping ground for other people's standards.
>
> In the proper context, I think it is more understandable why developers
> watching this situation unfold might think twice about fd.o "standards"
> if fd.o doesn't help reach a consensus that actually considers all
> voices and needs.

Absolutely.

But please understand that I'm not advocating a continuation of making 
specs into 'blessed' standards when they haven't achieved a reasonable 
level of consensus.  Going forward, I would be thrilled to see greater 
participation, and fewer people getting frustrated and going their own 
way.  But, that's the key bit: "going forward."  If going forward really 
does mean that the current org.freedesktop.Notifications interface 
cannot be turned into something we can all agree on without breaking API 
compat, then, sure, change the name and make the incompatible changes. 
But, as I said earlier, I don't think an incompatible change has been 
suggested or agreed upon.

>> Right, exactly.  Forgive me if I'm mainly considering *my* psychological
>> reasonings and emotions here, but they do exist as well.  I understand
>> that some people are rightfully annoyed at being mostly left out or
>> ignored when the current spec "hijacked" a name in the org.freedesktop
>> namespace, but that doesn't mean they should feel free to "retaliate" by
>> making extra work for those of us who have invested time in the old
>> interface.
>
> Again with "retaliation".  Believe it or not, the current (forced) spec
> really isn't seen to be sufficient.

That isn't at all clear.  Or rather, it isn't at all clear that the 
current spec (whether it was forced or not is irrelevant to the 
technical discussion) can't be molded into something sufficient without 
breaking backwards compatibility.  When that changes, sure, change the 
name and break API.

	-brian