Re: [Evolution] Delete messages on server when deleted locally
- From: guenther <guenther rudersport de>
- To: Bill Yohman <evolution designsco com>
- Cc: evolution lists ximian com
- Subject: Re: [Evolution] Delete messages on server when deleted locally
- Date: 03 Jun 2003 02:20:20 +0200
Sorry, that was my definition of being "designed" for some purpose.
I normally have a negative response when I hear someone use that phrase.
While it may not be the case in your instance, most of the time it's
followed with some cop-out as to why that's not the way to do it. I'm not
really interested in a philosophical discussion about mail clients so this
turns me off. Judging from your response you don't fall into this category.
You're right, I don't.
In fact, although I do not use POP3, I would love to see those functions
in Evolution. Just to get the killer-application in mailing and to give
the knowledgeable user the power.
My only purpose was, to give some explanation, why those features are
missing. I am just a helpful user, giving the community something back
this way.
Additional, it is very hard to see the knowledge background of the
person, posting a short question. So I might tell you what you already
are aware of, just by trying to give an explanation as detailed as
possible.
At least some Evo hackers are known to be very strict in RFCs and what
they had in mind. While this is IMHO good and reasonable, there are some
drawbacks. In this case, it should be no problem at all to implement the
mentioned features without violating RFC. AFAIK there are currently a
lot of tasks with higher priority...
Anything other than this is trivial
programming on the part of the application developer as demonstrated in a
number of other mail clients.
Granted, yes -- you can do better even with this very small set of
commands. But it always will be just some clever workaround.
Most of the things I do on a *nix command line are clever workarounds.
That's the beauty of the OS design. Believe me, if I could program in C (or
whatever Evolution uses, I would HAPPILY donate the code to make this happen).
LOL -- ack, *nix and its tools is all about making a hell of a lot out
of simple and efficient programs. :-)
I can understand that other features are more important and I have no
problem with that. What I don't like is when a developer tells me something
"wasn't designed that way and you should change over to the why that I
suggest." That's not his job. He should respond to the marketplace to the
best of his abilities.
Sure. But as I said some sentences ago, I am not a Evo hacker...
At least that is how I interpret chapter 1 of RFC 1939... ;-)
I agree but no one is asking for it to manage the mail. We don't want
changes we make to a message propagated back to the server. We just want
more granularity when it comes to the retrieval and deletion of messages. I
wouldn't suggest that someone create IMAP functionality in a mail client.
As this is Open Source (and you even would do it yourself, if you could)
I suggest at least raise your voice on bugzilla, letting the developers
know the users need it.
http://bugzilla.ximian.com
On a somewhat OT note: How do those mail clients handle it? I mean,
there is no big problem in deleting the mail on the server, when
deleting on your machine (as long as UIDL is implemented correctly...
see the archives).
But if you delete message ID-0001 on client A (and thus on the server),
and retrieve mails on client B -- is the mail being deleted on client B?
What if the feature "delete after x" days is set to 3 months, and the
user forgets to set system clock appropriate after system upgrade,
letting the false value at last year (I have seen too much mails exactly
one year behind). Are all mails being deleted? Before or after they were
retrieved?
...guenther
--
char *t="\10pse\0r\0dtu\0 ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]