[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: PATCH: Outlook compatible attachment naming
From:       Scott Wheeler <wheeler () kde ! org>
Date:       2004-04-29 12:55:17
Message-ID: 200404291455.17197.wheeler () kde ! org
[Download RAW message or body]

On Thursday 29 April 2004 08:08, Till Adam wrote:

> Ingo, in this particular case I think the benefit of standing strong on
> principles does not outweigh the negative effects for our users. While I
> certainly share your opinion that we should, whenever possible, be as
> standard compliant as possible and be rather strict in what we produce, not
> give in to market pressure from the Redmondians, etc, there is a limit to
> that. Not implementing the obsoleted rfc hurts a large and quickly growing
> part of our users in their every day mail usage. That's not a good thing.
> I've been very hesitant to admit that and have therefor refrained from
> commenting on this so far, but the refusal of those affected to accept the
> workaround have convinced me that this is much more than a minor annoyance
> for them.
>
> In short, I think we should consider implementing this, even if it means we
> optionally produce mails that are not adhering to the latest rfcs, but to
> an obsoleted one.
>
> What do the others think?

Well, as to this "limit" I must say that I agree.  I think anyone working on a 
tool which interacts with other frontends / clients / whatever always has to 
deal with this issue at some point.

Normally the criteria that I apply before adding something that I consider a 
"convenience hack" are (a) real world usefulness (i.e. the usage case mustn't 
be obscure) (b) "proprietary-ness" of the proposed change and (c) 
invasiveness of such a hack.  Even then I usually manage to work in a 
mini-rant somewhere in a dialog or such.

In this case (a) I don't think the usefulness is debated, (b) it's based on an 
RFC rather than something obscure and proprietary and appears to have at some 
point been correct and (c) the real "work" of the patch is one line of code.

There are certainly times where things aren't as self-contained and clear cut, 
but really it seems like the work going into avoiding including this is much 
more than the work required to make quite a few users lives easier...

-Scott

-- 
If you want to get laid, go to college, but if you want an education, go to 
the library.
--Frank Zappa
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]