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

List:       kmail-devel
Subject:    Re: CIA proposal (was: ClientInterface)
From:       Marc Mutz <mutz () kde ! org>
Date:       2003-07-22 11:49:04
[Download RAW message or body]

On Tuesday 22 July 2003 12:24, Andreas Gungl wrote:
<snip>
> However IMHO building a peer system is still more
> complex than a client server system as long as you have a single data
> source (in contradiction to distributed data with distributed
> responsibilities).
<snip>

This is not a peer-to-peer system as I understand it. It's just how on 
Unix programs managed to perform concurrent access to files for ages. 
Note how the "release folder" DCOP call isn't even stictly necessary. 
It's only a hint at the other process to work harder to release the 
lock earlier.

If _this_ is a p2p system, then KMail is one since it's very first days, 
since it uses file locking for /var/spool/mail/user :-o

The only thing that smells in any way like p2p here is the broadcast 
before compactification. But compactification is a noop for maildirs 
and only the (relatively small) index files are affected and only if 
there were many deletes recently. So I'd be cool with leaving index 
file compactification as something that is performed only in 
single-instance mode.

And if that is not acceptable and the list that dcopserver maintains is 
not sufficient for KMail, then one can still roll it's own instance 
registry by adding a ~/Mail/.instances{,.lock} that lists hostname and 
PID of each instance.

Marc

-- 
memAlloc() Amnesia Error: Out of Memory
_______________________________________________
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]