[Kde-pim] Akonadi design questions

[Volker Krause]

On Monday 11 June 2007 23:05:32 Christian Schaarschmidt wrote:
> > > I did some more doc reading. most of the documentation is available in
> > > doxy files, so techbase might not be such a good idea after all ... ;-)
> > > what about these ideas?
> > > - use bug.kde.org for todos, to seperate from real bugs we could use
> > > special component or target release. always up to date, you can
> > > assign/take the todo and close it with svn-commit
> >
> > interessting idea, I don't have any particullar preferrence here. But I
> > agree we need one maintained Akonadi todo list somewhere. With more and
> > more people getting interested in helping this would certainly help.
>
> ok, then lets try it ;-) where do we get a
> new product:akonadi
>                new component:server
>               new component: lib
>               new component: resource
>              ....

IIRC everyone with a svn account has enough access rights to add products and 
components. Having Akonadi in there will be needed sooner or later anyway.

> maybe a topic to be discussed with the other pim-guys at aKademy ?
> they might get "angry" if we start "poluting" bugs.kde.org with TODOs.

It's not like bugs.kde.org would be especially clean in the PIM area currently 
though ;-)
Will you be at aKademy? All the design stuff below is a lot easier discussed 
in person with a sheet of paper or a whiteboard to draw on ;-)

> > that all makes sense, feel free to change that stuff.
>
> ok
>
> > Thanks a lot for your work, it happens not very often there is someone
> > voluntarily helps with the docs ;-)
>
> don't "worry", that is just until I can start coding.
> I'll try to insert your answers were I see it fits, to be prepared for the
> next newbie ;-)
>
> this time I spent some time on thinking on the design it self. I would like
> to hear/discuss what you had planed to solve this topics:
>
>
> server/src/cachecleaner.cpp
> +    int expireTime = qMax( 5, policy.expireTime() );
> //why this 5 minutes minimum expireTime? I don't think this is
> documented...

hm, I don't remember why I added this, probably just a left-over from testing.

> imap resource
>   with caching disabled, how does kmail get informed about new mail?
>   as far as I understand it, no caching means no db-entry, hence no
>   SIGNAL

No caching means no local content, not no db entry at all. So, Akonadi always 
knows that a mail exists on the server, but not necessarily has any data in 
the cache. That's what is done by all resources we have currently, they only 
provide an empty item when listing a collection and content only on request.

> LDAP
>   How should searching be done?   downloading the complete LDAP directory
>   might not be possible/reasonable. Even if we do download we will never
> know if our copy is complete. nepomuk will only know about downloaded
> items. Concequence: search has to be part of resource, the resource knows
> how to contact the backend, local search can be delegated to nepomuk
>   Problem: if I configure one local addressbook and one LDAP, how can I
> search for contacts on both? I cannot go directly to nepomuk, because my
> LDAP copy might be incomplete.
>   Idea: searchProvider keeps track of what mimeType can be reached from
> which resource. does local search with nepomuk/strigi/XESAM and in paralell
> asks resources to update akonadi-db. monitors if resource has found more

The same problem happens with IMAP server-side search. The idea is (so far not 
yet implemented) to send the search query to the resources that support 
search as well and use local search for everything else. So, basically the 
same you came up with. But since all backends have different search 
capabilities, translating Akonadi queries (we might want to use the XESAM 
query language here, seems to cover all our needs) into backend queries might 
be incomplete in most cases. But that's as good as it can get without full 
download or restricting search to the lowest common denominator.

> strigi
>   and encrypted mail? I would say the user has to decide if those
>   mails should be indexed or not and the decryption job has to feed it to
>   strigi.  this might result in code duplication kmail/feeder; doing it in
> the backend doesn't fit to well into the content agnostic backend idea of
> akonadi.

Yep, that's definitely something the user has to decide. It's somewhat related 
with storing encrypted mails unencrypted locally. A "decryption filter" might 
help, but filtering is another large area that's not fully designed yet. 
There are some ideas about filter agents using pre-notification hooks which 
could provide a very powerful filtering infrastructure, but nothing concrete 
yet.

>   with leazy loading only envelops are loaded into akonadi. strigi has no
>   clue about the content until the complete fetch, hence the user wil not
>   find new mails. I am not sure if non-IT people will understand the
>   concequenses of leazy loading. I have no solution for that other than
>   good help/documentation ... or full load.

Yep, that can only be solved by full downloads or server-side search. The same 
problem existed in KMail and KNode in KDE3 without too much confusion, so I 
think it's understandable by normal users.

Btw, this is currently slightly broken since the strigi feeder fetches newly 
added items which triggers a full download. We probably need a protocol 
extension to fetch only local content to solve this.

> kaddressbook
>   future of contacts? In theory all the data for contacts we have
>   (name,address, birthday, ...) is metadata  that could (should?)
>   be stored in nepomuk

No idea, that's not my area ;-)
I'm not sure if this data can exclusively stored in Nepomuk, we need a way to 
sync changes back to eg. groupware servers.

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/20070613/232671a4/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/