Re: [Evolution-hackers] imap

On Fri, 2005-01-28 at 02:25 -0500, JP Rosevear wrote:
On Fri, 2005-01-28 at 11:20 +0800, Not Zed wrote:
> Well, derr, something that would be a supported option in 2.2, and
> default perhaps in 2.4.

Well, thats quite a bad breakdown in communication.
I just didn't think anyone would be rash enough to take such a high-risk approach.  It didn't even enter my head.
> The feature set isn't even the same, apart from it, well, not working,
> i've been wondering for days why imap on my workstation refused to
> connect to wal-3.  And i'm pretty fucking pissed off that i've been
> committing patches to code that is no longer built.

If there is a feature gap, I'd like to know (as would fejj and christine
I'm sure).  The main issue was the mailing list stuff, but fejj fixed
Well there are already bugs being filed about it.  No support for "connection command" for example.
this, at least in the List-Id case (unfortunately by having to use more
than ENVELOPE in the request, I understand he talked to you and found no
other way).
Hmm, not exactly.

I said he would have to override the search functions, and look up the full headers to calculate the mlist stuff if it was asked for and not available, at the very least.  Although in other ways it doesn't help since the ui wont fully work properly until that data is available in memory (i.e. contextual stuff on mailing list).  It could probably be calculated asynchronously too, and propagated using folder_changed events.  Personally i'd just have it as an option, and just disable the mlist stuff entirely and have it fun fast, or make it run slower and have it work.  But that only works if it is an alternative provider, of course.
As for it not working... its somewhat reasonable now in the (and
CVS HEAD) release but still has some issues.

Fejj and I discussed re-enabling the old code as imap-old:// or
something earlier this week, thats still a possibility.  A code audit of
the old imap code to look for workarounds that imap4 should take and
build up a test case list would be good as well.
Ok, well i'll leave you two to it then.

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