From kde-telepathy Mon Jan 21 21:09:14 2013 From: Martin Klapetek Date: Mon, 21 Jan 2013 21:09:14 +0000 To: kde-telepathy Subject: Re: Metacontacts/KPeople status Message-Id: X-MARC-Message: https://marc.info/?l=kde-telepathy&m=135880259818650 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============4344300644923403571==" --===============4344300644923403571== Content-Type: multipart/alternative; boundary=e89a8f5035106a2fcb04d3d2e182 --e89a8f5035106a2fcb04d3d2e182 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 21, 2013 at 2:00 PM, David Edmundson wrote: > On Mon, Jan 21, 2013 at 7:54 AM, Martin Klapetek > 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 > > > } > 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 --e89a8f5035106a2fcb04d3d2e182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2013 at 2:00 PM, David Edmundson <david@davidedmu= ndson.co.uk> wrote:
On Mon, Jan 21, 2013 at 7:54 AM, Martin Klapetek
<martin.klapetek@gmail.com<= /a>> wrote:
> Hey everyone,
>
Firstly, thanks for writing this.

> here's how it currently looks with our metacontacts. KPeople is fu= lly usable
> now. The API as well as the code needs some cleanup, but right now
> everything we want is there and working.
>
> Overview:
> =C2=A0* grouping/ungrouping contacts (even with non-IM contacts)
> =C2=A0* starting chats/audio/video
> =C2=A0* getting detailed info about persons
>
> What's missing
> =C2=A0* 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 thi= s to
> work sensibly. Right now we're getting data from Akonadi and Telep= athy. If
> we change say a nickname in contact list (with kpeople), this change s= hould
> be written back to Telepathy.

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 feature.

Indeed, should still be possib= le for the metacontact itself though.
=C2=A0

=
> Same goes for Akonadi of course.

Agreed, we also need to be writing in the IM address into Akonadi add= ress books.

I know there was a GSoC for= the writeback service, but I don't know the details. Awaiting Vishesh&= #39;s reply.
=C2=A0
>Otherwise
> we're in a state where two data providers have inconsistent data a= nd 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 locall= y. On the
> other hand, the grouping into metacontacts will also be just local. Vi= shesh,
> what's your take on this?
>
> =C2=A0* 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 cu= rrent
> (awesome) proxy filter
>
> =C2=A0* starting actions through KTp infrastructure
>
> - this is again so we can just switch the models on the fly and thus r= euse
> 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 thinki= ng
>
I'm thinking you forgot to finish that sentence :)

Eheh, no idea what I wanted to say there :D
=C2=A0

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);

> =C2=A0* grouping
>
> - should be fairly easy, the groups are present in Nepomuk, just not u= sed
>
> =C2=A0* contact's offline presence
>
> - for the contact list to work properly with kpeople, one needs to hav= e 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 sh= uts 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 cont= act
> 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&= #39;t
> start, the user is left with random invalid presences. It could write<= br> > 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 a= lmost
> realtime, but that means combining two models (where one queries the o= ther)
> 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<= br> only option:

This is how I imagined I would do it.

KPersonModel {
=C2=A0 //all contact stuff, except presence, caps, returns
Tp::UnknownPresence for presence role.
=C2=A0 data()
=C2=A0 rowCount()

}

KPeopleModelWithPresence {

=C2=A0data() {
=C2=A0 =C2=A0 if (role=3D=3D presenceRole) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 //get contact id from index (from other model),= look up
presence from hash
=C2=A0 =C2=A0 }


=C2=A0 =C2=A0 =C2=A0// this will also return ContactRole and AccountRole, s= o actions
in KTp automatically work.
=C2=A0}

=C2=A0 =C2=A0QMap<QString (contact uri), QPair<Tp::ContactPtr, Tp::Ac= countPtr> >

}

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 includin= g this.
=C2=A0
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.
=C2=A0- All the information is in one place, two sources is more complex vs
=C2=A0- 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.
= =C2=A0

> =C2=A0* good looking delegate for metacontacts
>
> - right now I'm simply painting the presences in a row with no ind= ication of
> "this is a metacontact" (except the multiple presences on on= e row).
> Double-clicking the item expands it and shows all the individual conta= cts.
> Ideas/mockups welcome.
>
> =C2=A0* good startup time
>
> - currently we're at ~3 secs before contact list shows up with ~80= 0
> 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 cr= eate
> 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<= br> communicating with packagers and users.

Blogposts, blogposts, blogposts...

--
<= span style=3D"color:rgb(102,102,102)">Martin Klapetek | KDE=C2=A0Developer<= /span>
--e89a8f5035106a2fcb04d3d2e182-- --===============4344300644923403571== 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 --===============4344300644923403571==--