From kde-telepathy Wed Jan 30 09:17:08 2013 From: Martin Klapetek Date: Wed, 30 Jan 2013 09:17:08 +0000 To: kde-telepathy Subject: Re: Metacontacts/KPeople status Message-Id: X-MARC-Message: https://marc.info/?l=kde-telepathy&m=135953747627912 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0970382615771275100==" --===============0970382615771275100== Content-Type: multipart/alternative; boundary=f46d04389321487ecd04d47dfb94 --f46d04389321487ecd04d47dfb94 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 25, 2013 at 6:09 PM, Vishesh Handa 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 --f46d04389321487ecd04d47dfb94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 25, 2013 at 6:09 PM, Vishesh Handa <handa.vish@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 ch= anges (not that cheap) and keep writing back to Akonadi and Telepathy. Addi= tionally, 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 accompli= sh 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 mos= t. So arguably that wouldn't be /that/ massive waste of resources. I al= so agree that "one directional" feed is better (changes done dire= ctly in backends like telepathy, refeeded into nepomuk through feeders).
=C2=A0
=C2=A0
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
<= div>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 Ak= onadi I guess. Unless we port everything to KPeople (KMail and friends), wh= ich might be the ultimate goal, but...someone needs to do it.
=C2=A0

My take wou= ld be to just write the data back in Telepathy (if possible), and let Nepom= uk update itself from the feeder, or manually update Nepomuk. Both approach= es work fine.

Synchronization is hard problem. In this case it does not seem li= ke really we need to synchronize anything.

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

=C2=A0* contact's offline presence
- for = the contact list to work properly with kpeople, one needs to have the ktp-n= epomuk-feeder running ALL the time. Once it's down, we're screwed. = Currently there's a different problem though - when the service shuts d= own (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 contac= t 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 off= line presence while being destroyed, but that would need to be synchronous = job which can take some time, which means delaying reboot/logout/whatever f= or no apparent/visible reason to the user. We were talking if we could reus= e KTp presences as we have them available in almost realtime, but that mean= s combining two models (where one queries the other) and I don't like t= hat 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.
=C2=A0

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

Exactly.
=C2=A0
=C2=A0* good startup time
- currently we're at ~3 secs before con= tact 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= 9;ll contact you ;)

Cheers
--
Martin Klapetek | KDE=C2=A0Deve= loper
--f46d04389321487ecd04d47dfb94-- --===============0970382615771275100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KDE-Telepathy mailing list KDE-Telepathy@kde.org https://mail.kde.org/mailman/listinfo/kde-telepathy --===============0970382615771275100==--