On Thu, 2003-01-30 at 23:15, Not Zed wrote: > > Of course, this doesn't mean that the work can't start now. :-) The > > IMAP rewrite could be maintained as a separate branch, and merged in > > after 1.4 is released. > > There's no need for any of this. It can be setup as a separate camel > provider which isn't compiled by default, using a different prefix. It > could even just be compiled separately from the main tree and plugged in > at run-time.
Oh, even better then. :-) I was assuming that rewriting the IMAP backend might also imply changing other parts of the library, but if that's not the case, all the better. > > If we start throwing in ideas for a better IMAP implementation, we > > should probably consider the issues with the current offline support as > > well?.. > > Unless we decide to make it properly atomic, this is independent of the > backend code. And even if we did its not that hard (and would probably > be inside camel). OK, so it sounds like we don't have to worry about this for now. I am not sure what you mean with "properly atomic" though, can you explain? -- Ettore Perazzoli <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
