Re: [Evolution] options on download

Ok, for your information, IMAP, when finished (the initial implementaion
may not do this, merely for expediency in having a working imap) will
not download any of the message except the header (the info needed
for the message list), until you are ready to view it.

Of course there will be options to download a bunch of stuff for
people who use imap in a more pop-like manner.

And it may be possible for it asynchronously download the normally
viewable parts in the background, but that's getting well beyond
the initial scope.

In short: anything that is possible may make it into evolution
one day, but some things take a lot longer to do than others.


PS as always, code speaks louder than words!

-----Original Message-----
From: NotZed [mailto:notzed helixcode com]
Sent: Thursday, June 01, 2000 8:23 PM
To: GLeblanc cu-portland edu
Cc: evolution helixcode com
Subject: Re: [Evolution] options on download

no need to grab a header and no need to check for mime attachments

Without doing those, you don't know how to download things, 
and get into
scheduling messes.  

Huh?  Dont know how to download what?  You were talking about file
sizes before, LIST provides that ...  The header doesn't even provide

Sorry, uhm, that wasn't what I meant.  The header provides the important
information for the software, but not a lot of information that's useful to
the user.  MS would like it if the user never saw/knew anything about the
header, and this hides it WAY far away.  (don't do that, it's a pain in the

ok, so none of this can work for POP, doesn't matter there.  I'll have to
think about that one a bit more before I come back and say anything else
stupid, give me a while yet.  As for the concept, downloading the "message
body" via IMAP, and waiting on binary attachments seems like it might be a
nice way to do it.   Maybe not, I don't know.  Later,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]