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

List:       kde-pim
Subject:    Re: [Kde-pim] akonadi and LDAP
From:       Volker Krause <volker.krause () rwth-aachen ! de>
Date:       2006-04-25 8:44:29
Message-ID: 200604251044.32738.volker.krause () rwth-aachen ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 25 April 2006 07:58, Till Adam wrote:
> On Monday 24 April 2006 19:53, Ismail Onur Filiz wrote:
> > * What exactly does it replace? I would guess in KMail the whole
> > ~/.kde/apps/kmail/{imap,dimap,mail,search} directories and a bit
> > more. The way I understood it, it is going to be the thing that
> > accesses actual maildir, ical, vcard files, ldap, exchange servers
> > etc. It will appear as a whole big 'virtual server' to the kdepim
> > applications. Is it correct?
>
> Yes.
>
> > * Connected to above, who talks to the imap, pop3 etc. servers? KMail
> > itself or akonadi?
>
> Akonadi. It's the central, desktop-wide mail service, which includes
> storage, syncing with servers and other providers (handhelds) and
> searching/indexing.
>
> > * How does the server itself store all data? Keep the maildir, ical,
> > vcard structure?
>
> Implementation detail. ;) Probably a mixture of native on-disk storage
> and db tables for indexing.
>
> > * How do libakonadi and akonadiserver communicate? dbus, dcop,
> > sockets?
>
> Currently the plan is for it to use a protocol based on IMAP for builk
> transfers and also for control traffic. I'm leaning towards making the
> control channel a dbus one instead, though. Haven't really thoroughly
> investigated that yet. In theory a dbus service could be build on top
> of the IMAP transport, on the library end.
>
> > * At which level is caching done? client or akonadiserver?
>
> All caching (other than for immediate display purposes) is in the
> server. That's one of the prime motiviations for having a central
> server, to be able to share caches and indeces.
>
> > * Who stores the indexes for folders in KMail? client or
> > akonadiserver? I understood that it is going to be an sqlite
> > database, and the schemas appear under akonadiserver directory, but
> > isn't it two steps of communication? i.e.
> > sqlite->akonadiserver->libakonadi?
>
> SQLite is supposed to be used for the initial backend implementation of
> the server. Yes, that means two steps, but the abstraction of the
> Akonadi protocol will require that in any case, no matter which storage
> backend we end up using.
>
> > * It looks like the account settings, categories are going to be
> > stored in the server ( as defined by PIM::Collection::Type ). To what
> > extent? Is it going to be that only configuration related to display
> > are going to be kept on the client side?
>
> We'll see, to be honest. This area is still muddy, at least in my mind.
> Volker has maybe thought about it more, in the meantime.

Account/resource settings need to be kept on the server if it should be able 
to sync your mails while kmail isn't running. Every account will provide a 
folder tree (that's why there is a collection type 'Resource' for the 
top-level collection defined by an account/resource)

I think categories are probably best handled by a hierachical tagging/labeling 
system, that could also be useful for the mail flags of kmail. To browse 
through the categories, a virtual collection tree could be created (that's 
why there is the 'Category' collection type).

> > * If akonadiserver might be used by Evolution etc. too, should it be
> > non-Qt ?
>
> It's currently Qt-only, meaning it has no KDE dependencies. According to
> the evo hackers I talked to a Qt dependency would be fine for them,
> their platforms ship it anyhow. Since we're currently the ones
> implementing it, why should we not use Qt? The libakonadi endpoints can
> be implemented in whatever language and toolkit people want to use, so
> a glib one is likely.
>
> > Eh, I guess that's all for now:) Thanks to the patient people who
> > attempt to answer all:)
>
> All of the above is my personal view on things, and by no means gospel.
> This is all open to discussion and improvement, it's merely what we've
> come up with so far, in our design discussions.

Same of course applies to my ideas about the collection stuff.

> Thanks for wanting to help with it. I wish I had more time to hack on
> it, myself. :)

regards
Volker

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

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