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

List:       kmail-devel
Subject:    Re: ClientInterface
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-07-20 13:29:21
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 20 July 2003 13:36, don@sanders.org wrote:
> Marc Wrote:
> > I think one of the use cases that the client/server split intented
> > to solve is having a KMail run permanently on the workstation
> > at work, while still being able to connect to the
> > then-kmail-server at work from home and check/read/send
> > mail.
> >
> > Correct me if I'm wrong and this is not one of the intended use
> > cases.
>
> This is not one of the intended use cases.

I agree with this. The intended use case is that the user starts another 
KMail client on his workstation at work from home. So server and client 
will be the same version.

> > Remember that the typical use case is to have very few (about
> > half a dozen max) clients, most of which are probably not even
> > interested in all accounts and all folders. If we require maildir
> > for concurrent KMail instances to work (which shouldn't be a
> > problem), then we don't have any locking issues with the mails
> > itself. Which leaves the index files, for which I don't see why
> > locking shouldn't work effectively enough.
>
> The problem is KMail can't handle foreign processes modifying it's
> index files, especially while KMail is running and the folder for
> that index file is opened. It's equivalent to having a foreign
> process corrupt memory in the KMail process.

No. It's not. If the index files are locked then at any time only one 
KMail can modify them. Of course the index file must not be locked the 
whole time a certain folder is visible but only if the index file is 
accessed.

> Also, to be honest I would prefer to avoid a maildir only limitation
> also.

Why? People who want to use several mail clients or several KMails will 
be happy to use maildir if this will allow them to do what they want.

Of course there are still those people that prefer mail clients that 
only talk mbox. If we can make it work for maildir then it shouldn't be 
that much harder to make it also work for mbox. But since with maildir 
only locking of the index files is required this is what we should 
start with. Also with maildir it's very unlikely that messages get 
corrupted because of corrupt indexes. With mbox this is much more 
dangerous because there the offset of the messages inside the mbox file 
might change. But with maildir all that could happen is that a message 
which is listed in the index doesn't exist anymore or that a message is 
missing from the index.

> > After all, for the
> > common case and except for the system
> > folders, the chance that two instances want to access the
> > same folder at the same time is negligible. In case of
> > collisions and for the system folders, simply making
> > instance-private copies of the index files is probably the
> > simplest method.
>
> I'm concerned with modification of a folder that is opened by
> multiple clients. Consider two clients with the same folder open, and
> outstanding deletes pending for that folder in both clients. Then
> when one client writes the index the other client will now have an
> out of date version of the index for that folder. So all the
> KMMsgBase objects will have invalid offsets into the index of their
> parent KMFolder. That's a problem.
>
> Maybe you could solve it by having each client make a private copy of
> the file data for any folder  that is opened, keep a record of what
> changes are made - disconnected imap style, and when the folder is
> closed merged those changes into the original folder. But I think
> that's a lot of unnecessary expense and fragility, and would prefer
> to avoid it. Especially as I'm trying to efficiently support search
> folders for global searches where many folders can be opened
> simultaneously.
>
> There are other problems also. Currently we do have model/view for
> folders (never mind the controller they went out of fasion in the
> 70's). When a folder is modified by one mainwindow then any other
> mainwindows are updated to show those changes, whether they be
> insertions, deletes or modifications. Now if one client has a folder
> open and pending changes, and another client makes repeated changes
> to the folder (like checking for mail) then how is the first client
> going to update the view when changes are made by the second client?
> Poll the index file, and completely reparse it whenever changes are
> made?

Exactly. You know that KDE provides easy-to-use classes for watching 
files, right?

> Another problem is serial numbers, if there are multiple clients each
> with their own serial numbers then duplicate serial numbers are going
> to be assigned.

This could be avoided by writing the next possible serial number to a 
file or, probably even better, by simply touching a file called 12345 
in ~/.kde/share/apps/kmail/serialnumbers/ where 12345 is the next 
available serial number. Each time a new serial number is needed KMail 
would look for this file, probably use a locking method to avoid a race 
condition, and then write/touch a new file. Of course this would be 
slower than a memory only solution. But at least it shows that the 
serial number problem is solvable. And it does even work for several 
KMails which run on different machines accessing the same home 
directory via NFS which the client/daemon solution can't solve.

Regards,
Ingo


[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail


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