Metacontacts/KPeople status

[Martin Klapetek]

On Fri, Jan 25, 2013 at 6:09 PM, Vishesh Handa <handa.vish at gmail.com> wrote:

>
> If we decide to only writeback changes back to Nepomuk. It will result in
> us having 2 additional processes which monitor the Nepomuk store for
> changes (not that cheap) and keep writing back to Akonadi and Telepathy.
> Additionally, we already have a process in Akonadi which writes data to
> Nepomuk, and the same for Telepathy.
>
> Do we really want 4 process continuously synchronizing all the data? It
> seems like a massive waste of cycles. Also, it doesn't really accomplish
> anything.
>

Two things I'd like to note here - the writeback would be quite sparse -
there won't be that much contact editing. Also one at the time at most. So
arguably that wouldn't be /that/ massive waste of resources. I also agree
that "one directional" feed is better (changes done directly in backends
like telepathy, refeeded into nepomuk through feeders).


>
> Here is the data that we currently have -
>
> 1. Basic contact data such as nickname, fullname, and other details
> 2. Contact groups and grouping information
> 3. Meta-contacts information: This person consists of these contacts.
>
> Does Akonadi need any of this information?
>

1. and maybe 2. I think. If you change a name of the (email) contact, you
surely do want this to have in Akonadi I guess. Unless we port everything
to KPeople (KMail and friends), which might be the ultimate goal,
but...someone needs to do it.


>
> My take would be to just write the data back in Telepathy (if possible),
> and let Nepomuk update itself from the feeder, or manually update Nepomuk.
> Both approaches work fine.
>
> Synchronization is hard problem. In this case it does not seem like really
> we need to synchronize anything.
>

So for now, I'll do just editing on Nepomuk level, ok?


>
>  * contact's offline presence
>>
>> - for the contact list to work properly with kpeople, one needs to have
>> the ktp-nepomuk-feeder running ALL the time. Once it's down, we're screwed.
>> Currently there's a different problem though - when the service shuts down
>> (logout or reboot for example), it leaves all the presences in Nepomuk in
>> whatever state they were. This means when you relogin and run the contact
>> list, all the contacts have wrong presences until the feeder kicks in and
>> puts correct data into Nepomuk. If the feeder for whatever reason won't
>> start, the user is left with random invalid presences. It could write
>> offline presence while being destroyed, but that would need to be
>> synchronous job which can take some time, which means delaying
>> reboot/logout/whatever for no apparent/visible reason to the user. We were
>> talking if we could reuse KTp presences as we have them available in almost
>> realtime, but that means combining two models (where one queries the other)
>> and I don't like that very much.
>>
>>
> Storing the presence in Nepomuk seems to cause more problems than it
> solves. Does it really solve anything?
>

Not anymore, with my super awesome presence model.


>
> We have all the data to fetch the presence in real-time - account
> identifier, and the contact identifier.
>

Exactly.


>   * good startup time
>>
>> - currently we're at ~3 secs before contact list shows up with ~800
>> contacts. I'll investigate where's the holdup and see what we can do about
>> it.
>>
>>
> I can help with this :)
>

Splendid. I'll contact you ;)

Cheers
-- 
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20130130/210a4490/attachment-0001.html>