[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-telepathy
Subject: Re: Metacontacts/KPeople status
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2013-01-21 21:09:14
Message-ID: CAPLgePrtOmP03dALwpadmNNnfGLaxA_8gtKLck6aZF2d9Z4WQQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Jan 21, 2013 at 2:00 PM, David Edmundson <david@davidedmundson.co.uk
> wrote:
> On Mon, Jan 21, 2013 at 7:54 AM, Martin Klapetek
> <martin.klapetek@gmail.com> wrote:
> > Hey everyone,
> >
> Firstly, thanks for writing this.
>
> > 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.
>
> Not many clients support changing names on rosters.. xmpp does.. but
> GTalk and Facebook won't support it. I'd be happy to not see this
> feature.
>
Indeed, should still be possible for the metacontact itself though.
> Same goes for Akonadi of course.
>
> Agreed, we also need to be writing in the IM address into Akonadi address
> books.
>
I know there was a GSoC for the writeback service, but I don't know the
details. Awaiting Vishesh's reply.
> >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
> >
> I'm thinking you forgot to finish that sentence :)
>
Eheh, no idea what I wanted to say there :D
>
> and are you sure we don't have an account? We set a imAccountUri
>
> and that account "object"
> imAccount.addProperty(Nepomuk2::Vocabulary::Telepathy::accountIdentifier(),
> path);
>
We do have it in Nepomuk, we just don't have it in the main model in
kpeople, it has as little stuff as possible to speed up the querying.
> > * 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.
> >
>
> "this means combining two models".
> I agree that would be convoluted and rather mental.
>
> What I don't agree with is that this means combining two models as the
> only option:
>
> This is how I imagined I would do it.
>
> KPersonModel {
> //all contact stuff, except presence, caps, returns
> Tp::UnknownPresence for presence role.
> data()
> rowCount()
>
> }
>
> KPeopleModelWithPresence {
>
> data() {
> if (role== presenceRole) {
> //get contact id from index (from other model), look up
> presence from hash
> }
>
>
> // this will also return ContactRole and AccountRole, so actions
> in KTp automatically work.
> }
>
> QMap<QString (contact uri), QPair<Tp::ContactPtr, Tp::AccountPtr> >
>
> }
>
Sounds good!
> This could happen either in the subclass, or an identityProxy model OR
> like TpQt has features that you pass to a constructor of the model, so
> it's all in the same class.
>
> We then strip presence/caps from the feeder.
>
> This keeps things lightweight for people who don't care about
> presences, in a design that I think is quite simple.
> It fixes all known bugs, (including one not listed.. you don't record
> streamtube/dbus tube caps)
>
Currently I think all the usecases do care about the presence.
Nevertheless, as I told DrDanz, I like this idea more and more, so I'll
work up a plan including this.
> And it removes load on the feeder so new accounts will be imported quicker.
>
> We then get into an argument over which design is cleaner.
> - All the information is in one place, two sources is more complex
> vs
> - The information is already available via dbus, and we have a
> fantastic library to get it. Proxying it through a database for no
> reason is more complex
>
True.
>
> > * 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.
> >
>
> I like this "0.6 as a tech-preview" idea. The hard part is
> communicating with packagers and users.
>
Blogposts, blogposts, blogposts...
--
Martin Klapetek | KDE Developer
[Attachment #5 (text/html)]
On Mon, Jan 21, 2013 at 2:00 PM, David Edmundson <span dir="ltr"><<a \
href="mailto:david@davidedmundson.co.uk" \
target="_blank">david@davidedmundson.co.uk</a>></span> wrote:<br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jan 21, 2013 at 7:54 AM, Martin Klapetek<br>
<<a href="mailto:martin.klapetek@gmail.com">martin.klapetek@gmail.com</a>> \
wrote:<br> > Hey everyone,<br>
><br>
Firstly, thanks for writing this.<br>
<div class="im"><br>
> here's how it currently looks with our metacontacts. KPeople is fully \
usable<br> > now. The API as well as the code needs some cleanup, but right \
now<br> > everything we want is there and working.<br>
><br>
> Overview:<br>
> * grouping/ungrouping contacts (even with non-IM contacts)<br>
> * starting chats/audio/video<br>
> * getting detailed info about persons<br>
><br>
> What's missing<br>
> * editing stuff<br>
><br>
> - this is very easy in terms of code, but becomes quite complex in the<br>
> bigger picture; we need writeback services in Nepomuk in order for this to<br>
> work sensibly. Right now we're getting data from Akonadi and Telepathy. \
If<br> > we change say a nickname in contact list (with kpeople), this change \
should<br> > be written back to Telepathy.<br>
<br>
</div>Not many clients support changing names on rosters.. xmpp does.. but<br>
GTalk and Facebook won't support it. I'd be happy to not see this<br>
feature.<br></blockquote><div><br></div><div>Indeed, should still be possible for the \
metacontact itself though.</div><div> </div><div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div class="im">
> Same goes for Akonadi of course.<br>
<br>
</div>Agreed, we also need to be writing in the IM address into Akonadi address \
books.<br></blockquote><div><br></div><div>I know there was a GSoC for the writeback \
service, but I don't know the details. Awaiting Vishesh's reply.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div class="im"> >Otherwise<br>
> we're in a state where two data providers have inconsistent data and \
that<br> > can lead to problems. OR we can do all changes only locally in \
Nepomuk.<br> > What's bad about that is that the changes will be kept only \
locally. On the<br> > other hand, the grouping into metacontacts will also be just \
local. Vishesh,<br> > what's your take on this?<br>
><br>
> * filtering & sorting<br>
><br>
> - we have a plan with David to have shared roles between models, so we can<br>
> switch models on the fly. Once we achieve that, we'll reuse the current<br>
> (awesome) proxy filter<br>
><br>
> * starting actions through KTp infrastructure<br>
><br>
> - this is again so we can just switch the models on the fly and thus reuse<br>
> all the existing KTp code paths. However one tiny issue is that we don't<br>
> have account info accessible in the main KPeople model. I'm thinking<br>
><br>
</div>I'm thinking you forgot to finish that sentence \
:)<br></blockquote><div><br></div><div>Eheh, no idea what I wanted to say there \
:D</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
and are you sure we don't have an account? We set a imAccountUri<br>
<br>
and that account "object"<br>
imAccount.addProperty(Nepomuk2::Vocabulary::Telepathy::accountIdentifier(),<br>
path);<br></blockquote><div><br></div><div>We do have it in Nepomuk, we just \
don't have it in the main model in kpeople, it has as little stuff as possible to \
speed up the querying.</div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> * grouping<br>
><br>
> - should be fairly easy, the groups are present in Nepomuk, just not used<br>
><br>
> * contact's offline presence<br>
><br>
> - for the contact list to work properly with kpeople, one needs to have the<br>
> ktp-nepomuk-feeder running ALL the time. Once it's down, we're \
screwed.<br> > Currently there's a different problem though - when the service \
shuts down<br> > (logout or reboot for example), it leaves all the presences in \
Nepomuk in<br> > whatever state they were. This means when you relogin and run the \
contact<br> > list, all the contacts have wrong presences until the feeder kicks \
in and<br> > puts correct data into Nepomuk. If the feeder for whatever reason \
won't<br> > start, the user is left with random invalid presences. It could \
write<br> > offline presence while being destroyed, but that would need to be<br>
> synchronous job which can take some time, which means delaying<br>
> reboot/logout/whatever for no apparent/visible reason to the user. We were<br>
> talking if we could reuse KTp presences as we have them available in almost<br>
> realtime, but that means combining two models (where one queries the other)<br>
> and I don't like that very much.<br>
><br>
<br>
</div>"this means combining two models".<br>
I agree that would be convoluted and rather mental.<br>
<br>
What I don't agree with is that this means combining two models as the<br>
only option:<br>
<br>
This is how I imagined I would do it.<br>
<br>
KPersonModel {<br>
//all contact stuff, except presence, caps, returns<br>
Tp::UnknownPresence for presence role.<br>
data()<br>
rowCount()<br>
<br>
}<br>
<br>
KPeopleModelWithPresence {<br>
<br>
data() {<br>
if (role== presenceRole) {<br>
//get contact id from index (from other model), look up<br>
presence from hash<br>
}<br>
<br>
<br>
// this will also return ContactRole and AccountRole, so actions<br>
in KTp automatically work.<br>
}<br>
<br>
QMap<QString (contact uri), QPair<Tp::ContactPtr, Tp::AccountPtr> \
><br> <br>
}<br></blockquote><div><br></div><div>Sounds good!</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> This could happen either in the subclass, or an \
identityProxy model OR<br> like TpQt has features that you pass to a constructor of \
the model, so<br> it's all in the same class.<br>
<br>
We then strip presence/caps from the feeder.<br>
<br>
This keeps things lightweight for people who don't care about<br>
presences, in a design that I think is quite simple.<br>
It fixes all known bugs, (including one not listed.. you don't record<br>
streamtube/dbus tube caps)<br></blockquote><div><br></div><div>Currently I think all \
the usecases do care about the presence. Nevertheless, as I told DrDanz, I like this \
idea more and more, so I'll work up a plan including this.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> And it removes load on the feeder so new accounts will \
be imported quicker.<br> <br>
We then get into an argument over which design is cleaner.<br>
- All the information is in one place, two sources is more complex<br>
vs<br>
- The information is already available via dbus, and we have a<br>
fantastic library to get it. Proxying it through a database for no<br>
reason is more complex<br></blockquote><div><br></div><div>True.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div class="im"><br>
> * good looking delegate for metacontacts<br>
><br>
> - right now I'm simply painting the presences in a row with no indication \
of<br> > "this is a metacontact" (except the multiple presences on one \
row).<br> > Double-clicking the item expands it and shows all the individual \
contacts.<br> > Ideas/mockups welcome.<br>
><br>
> * good startup time<br>
><br>
> - currently we're at ~3 secs before contact list shows up with ~800<br>
> contacts. I'll investigate where's the holdup and see what we can do \
about<br> > it.<br>
><br>
><br>
> If we can get at least the last 4 tasks sorted (plus filtering), I'm \
very<br> > happy to ship it with 0.6 as a tech-preview. The metacontacts users \
create<br> > in this should prevail once we get the full thing released.<br>
><br>
<br>
</div>I like this "0.6 as a tech-preview" idea. The hard part is<br>
communicating with packagers and \
users.<br></blockquote><div><br></div><div>Blogposts, blogposts, \
blogposts...</div><div><br></div></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