On Mon, Jan 21, 2013 at 2:00 PM, David Edmundson <[email protected] > wrote:
> On Mon, Jan 21, 2013 at 7:54 AM, Martin Klapetek > <[email protected]> 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
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
