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

List:       kmail-devel
Subject:    Re: CIA proposal (was: ClientInterface)
From:       Andreas Gungl <Andreas.Gungl () osp-dd ! de>
Date:       2003-07-22 10:24:27
[Download RAW message or body]

Am Montag, 21. Juli 2003 19:40 schrieb Marc Mutz:
> On Monday 21 July 2003 13:44, Andreas Gungl wrote:
> > Am Montag, 21. Juli 2003 13:31 schrieb Marc Mutz:
> > > CIA/4 can be extended with a DCOP broadcast call to all KMail
> > > instances to close F, so that A can perform (index file) compaction
> > > after all instances replied with a "folder F closed" message.
> >
> > How will you know all instances?
>
> dcopserver knows them all. The client/server concept has to solve the
> same thing, BTW.
>
> > Sending a broadcast is okay, but
> > collecting the responses would mean to have all instances registered
> > somewhere.
>
> dcopserver. The client/server concept has to... you know the rest ;-)
>
> > What about the situation where a registered application dies?
>
> dcopserver? If not, then the user gets prompted b/c of the timeout.
> Either she will know the cause already ("of course, my korg crashed!"),
> or can do something about it. The client/server .. you know.
>
> > Wait for a certain amount of time?
>
> Yes.
>
> > How will you know, that it really died?
>
> It doesn't respond anymore?
>
> > E.g. a long search operation could be running.
>
> <snip>
>
> Why should that stop the process from responding? Even now, I can type
> this email while performing a search and I think we agree that making
> all Kmail operations non-UI-blocking is a good thing to have in itself.
>
> You know, I can't understand why those points should be arguments
> against CIA/4, while at the same time you propose a much more complex
> protocol where almost every method call can timeout due to the DCOP
> peer dying or performing an expensive, blocking task?

For me it's a difference to have multiple instances running which all are 
allowed to modify the index files. If any connection get's broken, your 
files are ready for /dev/null.
Having a client server concept means only the single server instance is 
allowed to modify the index files. If a connection to a client breaks, then 
this is still no risk for your data.

I agree that the underlaying technical problems with respect to the timeout 
of the communication ore the registration are the same. I also don't say 
they are easy to solve. And finally we can discuss the kind of 
communication to be used. 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).

Regards,
Andreas

BTW I'm quite happy that Ingo and Don agreed that I can work on the 
separation of GUI and core code without involving an extra protocol. I've 
set up some small parts, but there are so many things to decide that I 
haven't to care e.g. for DOCP.
I'll provide first results before NH so that you can discuss my open issues 
and all other postponed issues there.

_______________________________________________
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]