[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-telepathy
Subject: Re: Metacontacts/KPeople status
From: Vishesh Handa <handa.vish () gmail ! com>
Date: 2013-01-25 17:21:41
Message-ID: CAOPTMKAQXxD6EMB-CggE_gX0hEMd45WVV+9DGqZrdRXBoqbChw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Jan 21, 2013 at 1:24 PM, Martin Klapetek
<martin.klapetek@gmail.com>wrote:
> Hey everyone,
>
Hey Martin
Sorry about the delay. Long emails and patches scare me.
> here's how it currently looks with our metacontacts. KPeople is fully
> usable now. The API as well as the code needs some cleanup, but right now
> everything we want is there and working.
>
> Overview:
> * grouping/ungrouping contacts (even with non-IM contacts)
> * starting chats/audio/video
> * getting detailed info about persons
>
> What's missing
> * editing stuff
>
> - this is very easy in terms of code, but becomes quite complex in the
> bigger picture; we need writeback services in Nepomuk in order for this to
> work sensibly. Right now we're getting data from Akonadi and Telepathy. If
> we change say a nickname in contact list (with kpeople), this change should
> be written back to Telepathy. Same goes for Akonadi of course. Otherwise
> we're in a state where two data providers have inconsistent data and that
> can lead to problems. OR we can do all changes only locally in Nepomuk.
> What's bad about that is that the changes will be kept only locally. On the
> other hand, the grouping into metacontacts will also be just local.
> Vishesh, what's your take on this?
>
>
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.
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?
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.
* 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?
We have all the data to fetch the presence in real-time - account
identifier, and the contact identifier.
> * 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 :)
>
> If we can get at least the last 4 tasks sorted (plus filtering), I'm very
> happy to ship it with 0.6 as a tech-preview. The metacontacts users create
> in this should prevail once we get the full thing released.
>
> The development is happening in branches - kde:libkpeople -
> mklapetek/toplevel_contacts and kde:ktp-contact-list - mklapetek/kpeople.
> I'll spend this week on cleaning up kpeople and tuning the performance.
>
> If you'd like to help out, let me know and I'll point out exactly what
> needs doing.
>
> Cheers
> --
> Martin Klapetek | KDE Developer
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, \
Jan 21, 2013 at 1:24 PM, Martin Klapetek <span dir="ltr"><<a \
href="mailto:martin.klapetek@gmail.com" \
target="_blank">martin.klapetek@gmail.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div>Hey everyone,</div></blockquote><div><br></div><div>Hey \
Martin<br><br>Sorry about the delay. Long emails and patches scare me.<br> \
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div>here's how it currently looks with our \
metacontacts. KPeople is fully usable now. The API as well as the code needs some \
cleanup, but right now everything we want is there and working.</div>
<div><br></div><div>Overview:</div><div> * grouping/ungrouping contacts (even with \
non-IM contacts)</div><div> * starting chats/audio/video</div><div> * getting \
detailed info about persons</div><div><br></div><div>What's missing</div>
<div> * editing stuff</div><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"><div>- this is very easy in terms of code, but becomes \
quite complex in the bigger picture; we need writeback services in Nepomuk in order \
for this to work sensibly. Right now we're getting data from Akonadi and \
Telepathy. If we change say a nickname in contact list (with kpeople), this change \
should be written back to Telepathy. Same goes for Akonadi of course. Otherwise \
we're in a state where two data providers have inconsistent data and that can \
lead to problems. OR we can do all changes only locally in Nepomuk. What's bad \
about that is that the changes will be kept only locally. On the other hand, the \
grouping into metacontacts will also be just local. Vishesh, what's your take on \
this?</div> </blockquote></blockquote><div><br></div><div>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.<br> <br>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.<br> <br></div><div>Here is \
the data that we currently have -<br> <br></div><div>1. Basic contact data such as \
nickname, fullname, and other details<br></div><div>2. Contact groups and grouping \
information<br></div><div>3. Meta-contacts information: This person consists of these \
contacts.<br> <br></div><div>Does Akonadi need any of this \
information?<br><br></div><div>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.<br> <br></div>Synchronization is hard \
problem. In this case it does not seem like really we need to synchronize \
anything.<br><br><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> * contact's offline \
presence</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>- 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.</div> \
</blockquote></blockquote><div><br></div><div>Storing the presence in Nepomuk seems \
to cause more problems than it solves. Does it really solve \
anything?<br><br></div><div>We have all the data to fetch the presence in real-time - \
account identifier, and the contact identifier.<br> <br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px">
</blockquote> * good startup time<blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"><div>- 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.</div> </blockquote></blockquote><div><br></div><div>I can \
help with this :)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px">
</blockquote><div><br></div><div>If we can get at least the last 4 tasks sorted (plus \
filtering), I'm very happy to ship it with 0.6 as a tech-preview. The \
metacontacts users create in this should prevail once we get the full thing \
released.</div>
<div><br></div><div>The development is happening in branches - kde:libkpeople - \
mklapetek/toplevel_contacts and kde:ktp-contact-list - mklapetek/kpeople. I'll \
spend this week on cleaning up kpeople and tuning the performance.</div>
<div><br></div><div>If you'd like to help out, let me know and I'll point out \
exactly what needs doing.</div><div><br></div><div>Cheers</div><span \
class="HOEnZb"><font color="#888888">-- <br><div><span \
style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></div>
</font></span></blockquote></div><br></div></div>
_______________________________________________
KDE-Telepathy mailing list
KDE-Telepathy@kde.org
https://mail.kde.org/mailman/listinfo/kde-telepathy
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic