On Wednesday 11 June 2003 05:37, Marc Mutz wrote: > On Tuesday 03 June 2003 12:53, Zack Rusin wrote: > > > > 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. > > > > 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