[Kde-pim] Decibel akonadi integration

[Friedrich W. H. Kossebau]

Hi,

may I add my wild and unfinished thoughts I developed from working on the 
(currently inactive) Khalkhi project.
(I cannot remember exactly what ideas there arose additionally at the Decibel 
meeting last year and am too lazy to dig them up right now, others might add 
them please).

Am Mittwoch, 20. Februar 2008, um 11:41 Uhr, schrieb Tobias Koenig:
> On Wed, Feb 20, 2008 at 10:06:24AM +0800, George Goldberg wrote:
> > On Feb 20, 2008 5:29 AM, Tobias Koenig <tokoe at kde.org> wrote:
> > > > If that should be integrated into KABC API or if there should be
> > > > another high-level contact API based on KABC and Akonadi is a
> > > > different problem, we haven't really solved that for the other types
> > > > either yet.
> > >
> > > Please add another API on top of Akonadi and KABC to not blow up the
> > > KABC API.
> >
> > I'm not quite sure what you mean by this. Since decibel takes care of
> > putting *all* presence into the storage itself, there is no need for
> > an API to store presence data, just to retreive it, which would be
> > done by the Akonadi::itemModel (above), woudln't it? Or have I
> > misundrstood this?
>
> There shouldn't be something like KABC::Addressee::setIMActive() or
> something like that... Instead there should be a separated API which
> fetches addressee objects and IM objects and presents them the user as
> unique object.

I agree. Why? Because the KABC::Addressee class should stay what it is, a 
collection of addresses (or more abstract: identifiers in systems) which 
belong to one entity (like a person). That is the data the addressbook 
software manages. And all data which belong to the systems should be managed 
by the software that functions as the proxy to the systems.
The relations of a id in a system to person object can be one-to-many for some 
(like birthday), one-to-one for other (like passport id, well, usually), 
many-to-one for most (like email) and perhaps even many-to-many (like?).

See e.g. all the status data assigned to a person object, I came up with when 
playing with the ideas driving Khalkhi:
* has birthday (in x days)
* is logged in to computer
* number of unread emails
* number of unread blog entries
* is available/not available/on vacation (by free/busy calendar)
* currently located at geo pos
* availabilty for chat
* currently in (video)phone call with me
You might be able to append other things to the list. And you might agree that 
adding calls for all such status information to the API of KABC::Addressee is 
not really what works best.

More, if in your code you want access to some status information, you for sure 
want to interact with the system in another way, too, like asking for some 
action, otherwise what would the status information be of use?
(Like KMail showing me the chat presence status and not allowing me to start a 
chat would suck, no?)
So you have to have an object representing that system around anyway. Best to 
query it directly for status information about the given id/address in that 
system. How the class(es) representing a system are implemented is of no 
further interest, can be done using Akonadi or not. Still, you might want to 
use Akonadi, as it has good connections to Nepomuk (does it? I have no clue).

Another thing are attributes the user assigns to certain addresses of entities 
in his addressbook:
* this email address is default
* phone number is home/work
* symbol to use in chat
* presence status to use for (always be offline for him)
* ...
or even the whole entity. Attributes, which might be used by code or just by 
the human. Well, some of this attribute data gets also be delivered by the 
holder of all the addresses. Currently some of it is already stored with the 
addressbook object and accessable by the API (like preferredEmail()). So I 
guess it should be also done for all other kind of these address types and 
their attributes. Or are there address types which are more equal than 
others? :) 

And this is where you might want a more general handling of address/id types 
and their attributes and all the rest. At least I did and started Khalkhi. Oh 
well... ;)

Gruß
Friedrich
_______________________________________________
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/