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

[Brian J. Tarricone]

On 06/25/2009 12:46 PM, Jeff Mitchell wrote:
> Brian J. Tarricone wrote:
>>>    "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.
>
> That's my point.

Just because software is maintained doesn't mean the maintainer should 
take the time to implement a change that amounts to a political decision.

>>>> 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?
>
> I wasn't involved in the original discussion either.  But you and I have
> differing opinions as app developers.  You see a change that is being
> proposed for purposes of clarification as busywork forced on
> ("punishing") everyone else.  I see a change that is proposed that will
> end up making all the code using it or wanting to use it more "clear"
> and understandable, and will not be terrifically difficult to implement.

True, we do appear to see things differently.  But I also see it from 
both ends: as an app developer, and as a notifications daemon developer.

If the only "incompatible" change is changing the interface name, and 
the API can or will remain the same (but presumably with 
backwards-compatible additions and extensions), then I submit that an 
interface change can be nothing more than busywork.  I'm sorry that you 
may not agree with that, but that's how I see it.

> If an fd.o spec is changed based on community consensus (and in this
> case, it's not  even changing an actual spec), I generally figure there
> were reasons, and I spend the small amount of time required to update my
> code.  Just like when libraries that I use break API or ABI -- I may not
> know the entire reasoning, but I figure the people working on the
> library had good reasons for doing so, and I fix it.

That analogy is somewhat incomplete: in this case *we* are the 
developers of the analogous "library," and *we* are the people who can 
-- and should! -- ask questions to be sure that incompatible changes are 
reasonable.

> I understand why you consider this busywork, but not all coding is fun.

Definitely true.  Bugfixing isn't fun either, but I'm happy to do that 
when there's a clear benefit.  (Ok, maybe "happy" isn't quite the right 
word, but you get the idea.)  Changing an interface name solely for 
appearance's sake doesn't fit into my conception of "clear benefit."

> I don't remember that statement (long thread) but I can see how you as a
> late-comer would see that dbus namespace usage and could easily figure
> it's a standard.  However, I would have thought when you failed to find
> documentation of the spec on fd.o's web site you'd have proceeded
> carefully

Yes, that it was hosted on galago-project.org did give me pause.  But at 
the time, IIRC, fd.o was having this big let's-disclaim-responsibility 
push to claim that fd.o standards aren't actually standards.  Hell, see 
http://www.freedesktop.org/wiki/Specifications right now -- it says in 
big letters at the top "These are not really standards."  So it was hard 
to say what constituted a good idea to implement... having 
"org.freedesktop." at the front of its interface name seemed like a 
decent enough criterion.

> -- if you developed based solely on the interfaces exposed on
> dbus instead of an actual spec/"API", then that's not dissimilar to
> making use of undocumented methods you found in libraries via "nm" and
> then complaining when the library maintainer yanks them away.  When I
> had to make use of HAL, I looked at the spec, I didn't just look at the
> output of "lshal -lt"...

Bad analogy and not at all representative as to what I -- and others -- 
did.  Who's talking about being dishonest, mmm?

> Right, OK, so I'll update my statement.  I haven't seen anyone state
> that they want to do this to punish anyone.

No, no one's come out and has directly said that, of course.  But 
changing an interface name *without needing to make incompatible changes 
to it* seems like nothing more than useless make-work to me.

Anyway, I'm kinda getting tired of this discussion.  It seems clear to 
me that I'm not really getting my point across (which is no one's fault 
but my own) and I'm not going to change anyone's mind here, so... that's 
it, I guess.  Feel free to change the name; I'm sure I'll grudgingly 
update xfce4-notifyd whenever I get around to it or someone submits a 
patch.  If the name change comes along with incompatible API changes 
that actually do improve the experience of developing against the spec, 
then maybe I'll feel a bit less grudging about it.

	-brian