Metacontacts/KPeople status

[David Edmundson]

On Mon, Jan 21, 2013 at 7:54 AM, Martin Klapetek
<martin.klapetek at 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.


> Same goes for Akonadi of course.

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

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

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


>  * 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> >

}

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)

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

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

> 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
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>