Re: [Evolution-hackers] Camel interfaces




IOffline or IOfflinable would be an ideal use for this - extra methods for stores which support online/offline mode.

As would ITransport and IStore for CamelServices which support both transport and store of mail.

etc etc (we could actually copy JavaMail more closely, ahem).

On Tue, 2004-11-02 at 17:38 +0800, Not Zed wrote:

Well, work in progress patch below, as seen on the blog.

The idea is to add interfaces to camel objects, this would let us do some things we currently have to extend every class for.

It might make it easier to support e.g. public folders, and so on.  We can just add an IPublicFolder interface to the store class rather than having to put in dummy callbacks for all stores.  Interfaces fix a lot of the locking issues too, by forcing each implementation to do all the work rather than try to inherit some stuff which just interferes with it.

I have an example 'interface' in camel-store in the patch, for subscriptions, although nothing is hooked up (nor is any of it tested yet apart from compiling).

(another one of the 'big things' i'm trying to get out the way before the eventual shift to a separate camel, in eds or otherwise).

--
Michael Zucchi <notzed ximian com>
"I'm stuck in a reality I can't imagine could be real."
Novell's Evolution and Free Software Developer
--
Michael Zucchi <notzed ximian com>
"I'm stuck in a reality I can't imagine could be real."
Novell's Evolution and Free Software Developer


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]