I just didn't think anyone would be rash enough to take such a high-risk approach. It didn't even enter my head.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.
Well there are already bugs being filed about it. No support for "connection command" for example.> 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
Hmm, not exactly.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).
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 1.1.4.2 (and CVS HEAD) release but still has some issues.
Ok, well i'll leave you two to it then.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.
