Hey, So personally i think we should disable/remove imap4 too and only because maintaining two implementations of IMAP without having *written* either is rather hard. And since we need to pick one which is closest to feature completion i guess IMAP would have to be the one.
A migration strategy is quintessential but i really have no expertise in making smart statements on the same. Also worth some thought is supporting multiple namespaces within IMAP which would make IMAP a super set of IMAP4. Thats my two cents worth anyway, Cheers, Shreyas On Wed, 2005-08-24 at 10:45 +0530, Harish Krishnaswamy wrote: > hey guys, > > Given that the two of you have a huge stake here - possibly to fix > bugs in IMAP4REV1 (if you choose so) - could you please let your views > on this known ? > > Harish > > On Mon, 2005-08-22 at 16:18 +0800, Not Zed wrote: > > We need to make a decision about imap4rev1. > > > We can either > > Leave it there, maybe add a warning about how buggy it is. We're well > > beyond string freeze though. > > > > Leave it there, but hack the code in nasty ways so that you can't > > create new accounts using it. Its a messy nasty hack. > > > > Remove it from the build entirely, and then add new migration code to > > switch it to the older 'imap' implementation, or some other equivalent > > switch over mechanism. The folder paths, foldernames, cache, summary > > files, are all probably so different as to make this a lot of work. > > > > Do nothing, don't make a decision. > > > > Anything other than removing it then needs another decision on whether > > we fix any bugs in the code or not. > > > > _______________________________________________ > evolution-hackers maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
