Re: [Evolution-hackers] idea for relocatable url's in mailer

[Not Zed <notzed ximian com>]

On Thu, 2003-09-25 at 02:58, Ettore Perazzoli wrote:
> I have the mailer displaying local folders now...  Now I have to figure
> out how to make the default folder settings and filters work again, so I
> have looked into this stuff a little more.
> 
> > - Url's internally in evolution (mail) merely reference an account,
> > plus a folder.
> 
> So, should we have something like
> "evomail:///<account_id>/path/to/folder"?
> 
> Each EAccount has drafts_folder_uri and sent_folder_uri members;
> currently they are physical (e.g. imap://), but I guess that changing
> them to using this evomail: scheme would work?

Since I presume they can point to anywhere, then making them use the
account-id scheme would make sense.

> > - they do this via a unique id which gets assigned to an account when
> > it is created.
> 
> We already have this, in the form of EAccount.  Each EAccount has a
> unique ID, although I think we need to add an EAccountList method to
> fetch the account by ID.

i know, but it was mentioned to explain the rest :)

> > - any access to camel is then remapped from that uid to another,
> > physically based one
> 
> I was thinking we could just have something like:
> 
> 	CamelFolder *mail_component_get_folder (const char *evomail_uri);
> 
> I don't think we actually need the physical URI anywhere aside from the
> CamelStore itself, do we?

Possibly something like that.  We do actually need the store too (for
the folder list), but that could be another function.

PS it would be em_get_folder or something, to match the new namespace.

> > The filter code, the mailer, would use these internal url's, so that
> > they would automagically update when the account changes, without
> > having to track and change them all the time.
> 
> Nod.  We still need to monitor folder changes though; if a folder is
> moved you still need to update the filters.

Yeah, it already does this, although the code could possibly be
simplified.