> >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="[EMAIL PROTECTED]"; 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; }}} _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
