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

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)=?iso-8859-1?q?
From:       Don Sanders <sanders () kde ! org>
Date:       2003-06-13 0:50:40
[Download RAW message or body]

On Wednesday 11 June 2003 05:37, Marc Mutz wrote:
> On Tuesday 03 June 2003 12:53, Zack Rusin wrote:
> <snip>
>
> > Personally I
> > like the way Outlook does it - meaning that the gui asks the core
> > for some specific info and the core just sends the data. So for
> > me DCOP communication.
>
> <snip>
>
> Sorry for disturbing the party, but did I miss something? Who had
> this glorious idea to make a "KMail server"?

As best I can tell the original architects of KMail had the idea, this 
is what KMKernel is about.

> If it's all about the old dream of a command-line KMail, then my
> take on this is that the non-GUI code needs to go into a separate
> lib and KDE and ncurses frontends linking to that. IIRC, DCOP needs
> an X server and I don't think you want that dependency for a
> mutt-like clone.

It's not just for a command line clone. A DCOP interface is a natural 
way for KMail to provide services to other KDE apps. Think about 
something like KAddressBook wanting to show all emails from a person 
in the address book.

It just so happens that DCOP is flexible enough that it could even be 
used to create a command line client. (KDE's first command line app?)

> As to concurrency: The better way IMO would be to make KMail
> reasonably robust against multiple instances acting on it's data
> (maildir should make this relatively painless) instead of cranking
> up a proprietary client/server protocol. That would automatically
> solve the procmail problem, too. That doesn't mean to go out of
> one's way to make it fool proof. It just needs to function well in
> the "keep running at work, but allow access at home, too" case. If
> you need full concurrent access, use an IMAP server.

This isn't just about access to maildir messages.

KDE apps increasingly need to access services that KMail can provide. 
Such services include creating composer windows, reader window 
widgets, search result widgets in addition to providing a uniform way 
of storing/retrieving/navigating mail stores whether they be 
maildir/mbox/imap/sql.

It's natural to use a KDE technology (DCOP interfaces) to provide such 
services to KDE apps. Calling such an interface proprietary implies 
all KDE interfaces are proprietary. It's true to some extent but 
people choose to use/develop KDE anyway.

I think it makes sense to take advantage of the work that has already 
been done and use the existing KMail process, than to bend over 
backwards trying to create a library that doesn't involve the use of 
a helper process.

> I don't see why DCOP needs to be involved at all. There's no reason
> for using it for UI<->code coupling. This is just a fruitless
> excercise in distributed system programming. Just think about all
> the error handling necessary to prevent a dcop shell command from
> interfering with a UI session. You'll end up sanitizing every
> little parameter to every little method call. And since you won't
> catch all cases anyway, you'll end up with all sorts of problems
> and prossibly even security bugs.

No this isn't necessary. Only the GUI code in the Kernel is a problem, 
and there's not too much of that.

> I prefer in-process method invokation over distributed systems
> wherever the latter is not strictly necessary. Don't use DCOP just
> because you've just had a read through your new CORBA book and it
> sounded cool!

DCOP doesn't require CORBA, it's more of a replacement for the subset 
of CORBA functionality that KDE requires.

> Please come up with a use case that requires DCOP/RPC and cannot be
> handled with simple library use!

One such use case is showing a virtual folder (dynamically updated 
search result widget) in KAddressBook. "Show me all the emails this 
person has sent me".

This probably could be done with a library that doesn't use a helper 
process, but it would require bending over backwards, and result in a 
needlessly complicated and probably inefficient solution.

> I mean, we use khtml and kabc as libs/parts, and not as server
> processes, or do we?

KMail actually relies on all kinds of server processes when using the 
KDE libs, kded, dcopserver, knotify, kio_uiserver, klauncher, ispell, 
kio_imap4, kio_pop3....

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