Metacontacts/KPeople status

[Martin Klapetek]

On Mon, Jan 21, 2013 at 2:00 PM, David Edmundson <david at davidedmundson.co.uk
> wrote:

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20130121/aebac8bd/attachment-0001.html>