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