[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-telepathy
Subject: Metacontacts/KPeople status
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2013-01-21 7:54:26
Message-ID: CAPLgePo2HzE=Uuf3R2bCfobnT=7OKDkP1f-S-6LLcz4W9wwjkg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hey everyone,
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?
* filtering & sorting
- we have a plan with David to have shared roles between models, so we can
switch models on the fly. Once we achieve that, we'll reuse the current
(awesome) proxy filter
* starting actions through KTp infrastructure
- this is again so we can just switch the models on the fly and thus reuse
all the existing KTp code paths. However one tiny issue is that we don't
have account info accessible in the main KPeople model. I'm thinking
* grouping
- should be fairly easy, the groups are present in Nepomuk, just not used
* 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.
* good looking delegate for metacontacts
- right now I'm simply painting the presences in a row with no indication
of "this is a metacontact" (except the multiple presences on one row).
Double-clicking the item expands it and shows all the individual contacts.
Ideas/mockups welcome.
* 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.
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>Hey everyone,</div><div><br></div><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><div> * filtering & sorting</div><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"><div>- we have a plan with David to have shared roles \
between models, so we can switch models on the fly. Once we achieve that, we'll \
reuse the current (awesome) proxy filter</div>
</blockquote><div> * starting actions through KTp infrastructure</div><blockquote \
style="margin:0 0 0 40px;border:none;padding:0px"><div>- this is again so we can just \
switch the models on the fly and thus reuse all the existing KTp code paths. However \
one tiny issue is that we don't have account info accessible in the main KPeople \
model. I'm thinking</div>
</blockquote><div> * grouping</div><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"><div>- should be fairly easy, the groups are present in \
Nepomuk, just not used</div></blockquote><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><div> * good looking delegate for metacontacts</div><blockquote \
style="margin:0 0 0 40px;border:none;padding:0px"><div>- right now I'm simply \
painting the presences in a row with no indication of "this is a \
metacontact" (except the multiple presences on one row). Double-clicking the \
item expands it and shows all the individual contacts. Ideas/mockups welcome.</div>
</blockquote><div> * good startup time</div><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><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>-- <br><div><span \
style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></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