[Kde-pim] the new message libraries

[Volker Krause]

Hi,

with the first merging attempt of libmessageviewer failed and having to wait a 
long time for svnmerge again, I can write another long email ;-)

As mentioned in the "Mailreader status and RFC" thread already, we will have a 
few libraries dealing with various aspects of emails (and also useable for 
news articles of course). The first one (libmessagelist) has already been 
merged, the second one (libmessageviewer) is currently resisting its merge 
from the akonadi-ports branch to trunk. Another one (composer) is work in 
progress there and Thomas has another one in mind (templates) I think.

All of them are build on top of KMime and Akonadi. However we don't want them 
to be part of any of the two (Akonadi is type-independent, KMime is 
Akonadi-independent and deals with a much lower level), so having them in 
separate libs is just fine. It wouldn't be fun though if they wouldn't share 
some additional code, which currently is dumped into libkdepim in good old 
tradition.

Now I can hardly call for a stop to adding new stuff to libkdepim and merge a 
whole bunch of stuff into it today. So, one suggestion would be to have 
a "libmessagecore" or something like that for shared parts between them. 
Current candidates are eg. the attachment properties dialog or the message 
status conversion utils (KPIM::MessageStatus). There is a slight risk of 
ending up as a mix of various things as well, but at least those would be 
somewhat related.

The final thing is naming. Since this is new stuff we are not yet bound by any 
restrictions regarding moving/renaming. The suggested common "Message" 
namespace for all of them had to be dropped again, it clashed with 
KMime::Message. You can of course solve that by fully qualifying the type 
names, but that simply made the whole thing way too inconvenient to use.
I think we currently have "MessageList" and "MessageViewer", which seems ok to 
be, though a bit long maybe. Any other suggestions?

Besides namespaces there is also the naming of the corresponding folder, or 
rather should a "lib" prefix be used or not. In kdepim we currently have a 
mix of both, we might want to standardize on one. Personally, I prefer to not 
use it, since that simplifies moving to kdepimlibs and allows nicer include 
paths that match the namespace.

regards
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091006/4a17e181/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/