Re: [Evolution-hackers] imap cache proposal

[Not Zed <notzed ximian com>]

On Tue, 2003-07-22 at 06:22, Jeffrey Stedfast wrote:
> Dan Winship wrote:
> 
> >>Anyways, the idea is that if we make it so that the location of the IMAP 
> >>cache is part of the account config rather than being a path that the 
> >>imap store creates itself during instantiation, we could more easily 
> >>delete the cache when the user deletes his/her account (because the 
> >>mailer would know where the cache dir was).
> >>    
> >>
> >
> >The mailer already can know that. Just call camel_service_get_path()
> >on the CamelImapStore. Everything underneath that directory can be nuked
> >when the account is deleted.
> >
> 
> this assumes the object is instantiated which isn't necessarily the case 
> (could be disabled).

But it could easily be instantiated in a non-connected state if
required.

But really, the cache is not something the mailer should need to know
about in the first place.  And there's nothing to say it (or similar
types of run-time data) would have to be stored on the filesystem in
that way at all (e.g. remote or local rdbms or something).

Maybe it should just have a delete or remove method to delete any
non-server related data, that can be run on a non-connected instance.

The idea of decoupling the 'account info' from the 'account instance'
probably makes sense, although it should probably be more far reaching
than this.  The code already has a mix of physical account vs evolution
account which is a bit messy.