[Kde-pim] [Decibel] Decibel akonadi integration

[George Goldberg]

On Wed, Feb 20, 2008 at 12:07 PM, Matt Rogers <mattr at kde.org> wrote:
>
> On Tue, Feb 19, 2008 at 08:32:49PM +0100, Kevin Krammer wrote:
>  > Hi Tobias,
>  >
>  > On Tuesday 19 February 2008, Tobias Hunger wrote:
>  > > On Tuesday 19 February 2008, Kevin Krammer wrote:
>  > > Hello Kevin!
>  > >
>  > > > IMHO presence information is too short lived to make sense for storing in
>  > > > Akonadi.
>  > >
>  > > We had this discussion before at our Decibel Hackathon in March last year.
>  > > Everybody agreed that the information needs to be stored in Akonadi (this
>  > > includes Volker Krause). Akonadi was designed to be a unified PIM data
>  > > storage engine, so let's just use it.
>  >
>  > I certainly agree if it is about data such as conversation history and maybe
>  > last seen, last event, etc, but presence doesn't sound like the kind of data
>  > that needs persistant storing.
>  >
>  > For presence I was more thinking along the lines of KIMProxy in KDE3, which
>  > used KABC identifiers for associating IM contacts with addressbook entries.
>  > When an application like KMail wanted to get the presence of a specific
>  > addressee it could ask the IM proxy and monitor its signals for changes.
>  >
>  > > > However, it will be good to have the IM "address" as part of a PIM
>  > > > contact data, i.e. inside the respective addressee (and probably create a
>  > > > new one if there isn't a matching one yet)
>  > >
>  > > Addresses and state (presence and last seen info, etc.) need to be stored
>  > > together.
>  >
>  > I am afraid I don't get the concept of storing a connection state like thing
>  > such as presence.
>  >
>  > Since everybody else seem to like the idea, I'd like to ask to at least keep
>  > it away from the addressee objects, otherwise Akonadi clients have to deal
>  > with full addressee re-transmissions (potentially including image/photo data)
>  > whenever people's auto-away functions kick in and whenever they return.
>  >
>  > Cheers,
>  > Kevin
>  >
>
>  I agree with Kevin when he says that presence doesn't make sense for
>  persistant (i.e. on-disk) storage. From my understanding, the whole point of
>  using telepathy, tapioca, and decibel is so that presence information can be
>  queried from decibel over d-bus when that information is needed.
The problem I can see with this is that decibel contacts should be as
integrated as possible with local addressbook contacts. So, if for
example, an app that displays a users contacts  wants to also show if
they are currently online or not, it doesn't have to get the contacts
from akonadi, get the contacts from decibel and then try and match
them together.

If I understand akonadi's role correctly, decibel should be able to
put the presence data into its cache so that apps only need get the
contact from one place - including his online status.

> Do I  understand incorrectly?
I can't answer that! I'm not sure I understand either, but hopefully
we can work out the solution through this discussion :)

George
_______________________________________________
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/