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

[Brian J. Tarricone]

On 06/25/2009 12:00 PM, Jeff Mitchell wrote:
> 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.
>
> That statement isn't entirely honest.

Yes, it's completely honest.

>  The problem is not just (or even
> mainly) that the spec wasn't standardized in the proper way, the problem
> is that the spec isn't robust enough for the needs of some of the active
> members of this community (whose voices were raised and ignored, with no
> consensus or official spec ever finalized).

Where is the current API being broken by the changes suggested on this 
list?  I'll admit I haven't kept up with the thread as well as I'd like 
since it's seen a lot of activity, and I've been out of town for a few 
days.  But from today's and yesterday's posts, it seems like the current 
renaming discussion is presupposing that the changes with the most 
consensus right now do not break backwards compat.

> Keeping backwards-compatibility in the spec for a period of 1-2 years so
> that app maintainers can code in some fairly straightforward changes
> doesn't seem like an onerous burden (I don't see HAL apps complaining).

While I understand David Zeuthen's reasons for wanting to redo HAL the 
"right way," I still resent having to rewrite my HAL-using apps to work 
with udev/DK/DK-disks/DK-power/etc... as well as figuring out which in 
all that mess I need to use and how to use it.  There, a HAL user just 
complained -- happy?  But that's for another discussion...

>   "Breaking five years' worth of software" is not really an honest
> statement either, unless you're talking about five years of unmaintained
> software (considering that apps/libraries could have a long period of
> time in which to transition, which would certainly be long enough for
> maintained software to make that transition...and for unmaintained
> software, that's why it's Open Source).

Uh... please point to this software that is not maintained.  libnotify 
is maintained, though doesn't see frequent releases (releases it doesn't 
really need).  notify-osd is maintained.  xfce4-notifyd is maintained. 
notification-daemon is possibly unmaintained, but has also seen a 
release last November.  I'm really tired of the common misconception in 
the OSS world that just because a piece of software hasn't seen a 
release in a while it means it's unmaintained or somehow broken or not 
useful or used in the real world.

> I don't think the "dick move" here is people raising the same objections
> that they raised years ago.

Correct: no it's not.  But don't put words in my mouth, as that's not 
what I said at all.

>> 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)
>
> (Maybe people simply got tired of being ignored.)

I can understand that, but I still resent having extra work put on my 
plate now because those same people have decided to get involved again. 
  I wasn't involved in the original discussion.  It wasn't due to 
inattention: I just wasn't involved in fd.o at that time (and I may not 
have been involved quite as much in desktop-level OSS at all, even). 
I'm sorry I haven't been around for more than 5 years.  Do you feel the 
need to penalise me for that?

>> 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.
>
> I didn't see anyone say it was your own damn fault, but I might have
> missed that; it's a long thread.

I believe someone (possibly Aaron) did say something to the effect that 
people who jumped on a non-community-blessed spec (despite the namespace 
usage) shouldn't be surprised when that spec changes.  From my 
perspective as a late-comer, it seemed community-blessed to me.  Clearly 
that assessment was in error, but how was I to know?

(This is of course a great argument for why this sucks a lot -- I took 
"org.freedesktop.XYZ" to mean there was community consensus when there 
apparently wasn't.  I *do* feel a bit misled, and I certainly sympathise 
with efforts to avoid this sort of thing happening again in the future, 
but... again: I hate extra make-work that doesn't serve a useful 
technical purpose.)

>  (Unless you're part of Galago, in
> which case, yes, people are saying it's your own damn fault.)  The
> message I've been hearing is not "those various apps/libraries should
> have known better", rather "how can we make the spec what we need and
> make the transition simple and relatively painless for apps and libraries?"

Right, I'd love to hear that too: but making things simple and 
relatively painless includes considering not changing the interface name 
for backwards compat reasons.

If there *really* isn't a good way of keeping the current API while 
adding the new flexibility and functionality people want, then by all 
means, change the name of the interface.  But that hasn't been the -- 
possibly mistaken -- impression I've gotten with the recent discussion 
of changes.

>> 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.
>
> I haven't seen anyone state that they want to do this to punish the
> Galago guys.

The galago people aren't the only "other side" stakeholders here.  Other 
people (such as myself) have implemented the current spec and are not 
involved in the galago project at all.

	-brian