Re: [Evolution-hackers] posting to folders

[Not Zed <notzed ximian com>]

On Mon, 2004-05-24 at 21:58 -0400, Jeffrey Stedfast wrote:
> On Mon, 2004-05-24 at 21:39, Not Zed wrote:
> > On Mon, 2004-05-24 at 09:55 -0400, Jeffrey Stedfast wrote: 
> > > On Mon, 2004-05-24 at 09:50, Dan Winship wrote:
> > > > On Mon, 2004-05-24 at 16:08 +0800, Not Zed wrote:
> > > > >   Even IMAP's APPEND function works without a selected folder, so our
> > > > > api forces fairly low-performance (not that it is a particularly
> > > > > commonly used thing).
> > > > 
> > > > If your Sent folder is on an IMAP or Exchange server, there's a
> > > > mysterious long delay after the first time you send email in a session,
> > > > while evo syncs up with that folder so it can append the new message.
> > > > This API would fix that.
> > > > 
> > > > And we could do the same optimization on move/copy too, which is a lot
> > > > more common (and has the same problem: the first time you move a message
> > > > to a given folder, there's a long delay).
> > Well the main problem here is we're going to have to use the folder in
> > most cases anyway - because users want their damn folders to update
> > immediately when they move messages around.  If we're just updating 'a
> > bit later on' we'll get bug reports.  And for move between imap
> > folders on the same folder, its much better using imap copy. 
> > > while I agree with the general idea of this, I'm not really liking the
> > > API that much. What I'd *really* like to see is the ability to
> > > instantiate a CamelFolder object without actually needing to "open" it.
> > > 
> > > This would solve both of these issues without the need to change the
> > > APIs that much. Also, we probably want things to work like this in the
> > > long run anyway... 
> >
> > Agreed, but another api is still needed for cross posting.
>
> yea, I suppose it would. What if NNTP just implemented the Transport
> interfaces?

Well they're really only for sending to rfc822 addresses I guess.  i.e. how are we going to route the right addresses to the right transport?

I guess its an idea though, but the proposed interface isn't really much more than having the same interface on a store.

I don't think this would make sense unless we just got rid of CamelTransport entirely and just having it as virtual methods and capability bits on CamelStore?  Could this simplify the store is also a transport issue?(or if we had interfaces on camelobjects and did it that way instead).

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.