[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI
From:       Don Sanders <sanders () kde ! org>
Date:       2003-07-27 22:21:33
[Download RAW message or body]

On Monday 21 July 2003 18:38, Martin Konold wrote:
> Am Montag, 21. Juli 2003 04:38 schrieb Don Sanders:
>
> Hi Don,
>
> > > If you want different clients to concurrently access the mail
> > > storage use IMAP.....
> >
> > The problem with this suggestion is that even for IMAP KMail
> > needs a local representation of what's on the server. eg. dimap
> > uses a maildir representation.
>
> No, this is not an issue at all.  By definition dimap uses a 
> _private_ local cache. No external program is under any
> circumstances allowed to make any use (reading or writing) of this
> cache. The fact that the current code uses the maildir format is
> completly irrelevant here. dimap could also have been implemented
> using some object serialization method.
> Maildir was simply chosen because it is a reliable and performant
> data structure to store mail data on disk.

Right, it doesn't matter whether KMail uses maildir or mbox or 
something else but it does matter that it uses some local 
representation. That a local representation exists.

> > We want to allow multiple clients to access this local
> > representation.
>
> Why? It makes definetly _no_ sense in the dimap case.

It makes sense even in the dimap case. We are talking about the case 
of multiple clients running on the same machine. It doesn't make 
sense for each client to have it's own private local cache. For me 
that would mean that each new KMail client would have to copy ~2GB of 
data, or re-retrieve that data from the server. I don't consider that 
acceptable behavior.

Hence the private caches should be shared.

> > Thus we have a case of multiple processes (one for each client)
> > accessing a shared resource (the local representation) and hence
> > we need a mechanism to manage access to that resource.
>
> I am afraid that your presumptions are invalid initially.

It's possible we disagree as to whether the local imap representation 
should be shared.

Personally I think it's clearly a good idea to share the local imap 
representation amongst kmail instances.

> > > IMHO the current proposal is completeley overengineered and
> > > reinventing the wheel.
> >
> > It's the simplest solution I know of and in my opinion the only
> > feasible solution presented thus far.
>
> I think we have to go back to defining the problem before trying to
> find the solution.

Componentizing KMail so that the Composer, Mail Reader and 
Folder/Messages list can be embedded in other apps. My traditional 
example being a search folder and mail reader in KAddressBook.

Don.
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]