Re: [Evolution-hackers] IMAP4REV1

[Jeffrey Stedfast <fejj novell com>]

Not Zed wrote:

> > > 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.
> > >      
> > Migration code, is a pretty good idea. IMHO we should do this.
> >    
>
> We don't really have much time to do this though.
>
> I'm not sure how much effort is involved.  Jeff?  Do you have an opinion
> on this?

couple thoughts:

how many people really use imap4?

I'm definitely not against removing it from the build (or at least 
disabling it by default in configure.in unless --enable-imap4 is specified?)

>  Do you think imap4 is worth keeping

not worth keeping as far as being shipped with evo rpms - serves as a 
somewhat useful example implementation for people to read over when 
implementing their own providers I would guess tho... but that's about 
it really, being so incomplete and untested and unmaintained, I really 
can't suggest it remain a part of the default build.

> , and if not how much
> effort is a migration code?
>  

I remember when I was originally writing the summary code, in an effort 
to avoid the need for actually migrating old imap summary files I had 
kept them the same format... I'm fairly certain (unless stuff has 
changed in the "imap" summary format) that imap4 can read imap summary 
files, but it *may* write out variables that imap doesn't know about.

a simple migration might just require a slight change to imap-summary.c 
to read in the extra variables that imap4 might save in the header (and 
disregard them).

the cache hierarchy is different (imap4 uses CamelDataCache), but not 
that important to migrate anyway imho.


migration of the urls shouldn't be too complicated, the paths have 
changed - imap4 uses the fragment for paths - but I think that's it 
other than the obvious protocol string change. Actually, probably don't 
even have to worry about the url paths anyway since provider urls are no 
longer used in filters.xml/vfolders.xml - you just care about the 
account url which afaik, just requires the protocol string change.

Jeff