--===============7354525519171366849== Content-Type: multipart/alternative; boundary=20cf3040ee5e94e9d504d3d2ac81 --20cf3040ee5e94e9d504d3d2ac81 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 21, 2013 at 11:00 AM, Daniele E. Domenichelli < daniele.domenichelli@gmail.com> wrote: > On 21/01/13 08:54, Martin Klapetek wrote: > > * 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 is something I've been wondering for a while... why should we have > the presence in Nepomuk, when we can just query telepathy? > We can have a method _in the library_ that returns you one presence for > your metacontact, but it doesn't mean that we need to store it in Nepomuk. > You can just connect to the required signals when you create the model > and keep the model updated. > Mostly historic reasons. The feeder was written this way sometime ago and I just used what was there - taking the presence from Nepomuk - to have something working and ready for testing. It is fast enough; the delay is minimal (~200msec). But more and more I'm actually inclining to what you propose, it would also ease up some Nepomuk activity, which is good I guess. > Anyway, imho KPeople library should have some initialization method that > checks if ktp-nepomuk-feeder is running and fails if it is not (or > perhaps tries to start it before failing). It could also watch its dbus > name and enter some error state when the ktp-nepomuk-feeder disappears. > So when it is in error state you can just return presence-unknown... > Yep, good idea. Noted. > > * 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 > > Again I suggest not to keep this in the model, We should have a method > in the library that queries nepomuk directly for the accounts, then > depending on the account type checks which actions are available. > Storing this kind of information on nepomuk is in my opinion useless > Yes, that is all present. Let me rephrase - kpeople can start actions solely on its own, but the account id is not in the main model to speed up data initialization (it is in Nepomuk) and also because it's needed only for the purposes of starting chat. Currently what happens is that when you double-click a contact, Nepomuk is queried for the needed details and then starts an action. > > * 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. > > That not good! :P Fix it! :D > Yeah, but it *is* huge improvement over what it was before :P Still unacceptable though. > I wonder if we had a DBus service that adds an additional layer between > nepomuk, telepathy, akonadi and the library would improve this > situation. It is an extra layer, but could allow you to save some time > at startup since it doesn't need to be initialized for every program > linked to the library. > But then we should also have something similar to TpQt "Features" so > that the service can avoid connecting to everything when nobody is using > it. But then you need again time to initialize the features you need... > Oh well. It was just a random thought. > I like the features idea. This needs thinking through though - get a list of apps that will use kpeople and how, list possible use cases/scenarios and see if the features would really be helpful or if we should just query for everything at once. I'm also thinking about lazy initialization - query the basic data needed for display, then do second run where we query for the data we don't need right away (like contact ids etc). And add them to the model. It is flexible enough to do that. -- Martin Klapetek | KDE Developer --20cf3040ee5e94e9d504d3d2ac81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2013 at 11:00 AM, Daniele E. Domenichelli <da= niele.domenichelli@gmail.com> wrote:
On 21/01/13 08:54, Martin = Klapetek wrote:
> =C2=A0* contact's offline presence
>
> =C2=A0 =C2=A0 - for the contact list to work properly with kpeople, on= e needs to
> =C2=A0 =C2=A0 have the ktp-nepomuk-feeder running ALL the time. Once i= t's down,
> =C2=A0 =C2=A0 we're screwed. Currently there's a different pro= blem though - when
> =C2=A0 =C2=A0 the service shuts down (logout or reboot for example), i= t leaves all
> =C2=A0 =C2=A0 the presences in Nepomuk in whatever state they were. Th= is means
> =C2=A0 =C2=A0 when you relogin and run the contact list, all the conta= cts have
> =C2=A0 =C2=A0 wrong presences until the feeder kicks in and puts corre= ct data into
> =C2=A0 =C2=A0 Nepomuk. If the feeder for whatever reason won't sta= rt, the user is
> =C2=A0 =C2=A0 left with random invalid presences. It could write offli= ne presence
> =C2=A0 =C2=A0 while being destroyed, but that would need to be synchro= nous job
> =C2=A0 =C2=A0 which can take some time, which means delaying
> =C2=A0 =C2=A0 reboot/logout/whatever for no apparent/visible reason to= the user.
> =C2=A0 =C2=A0 We were talking if we could reuse KTp presences as we ha= ve them
> =C2=A0 =C2=A0 available in almost realtime, but that means combining t= wo models
> =C2=A0 =C2=A0 (where one queries the other) and I don't like that = very much.

This is something I've been wondering for a while... why should w= e have
the presence in Nepomuk, when we can just query telepathy?
We can have a method _in the library_ that returns you one presence for
your metacontact, but it doesn't mean that we need to store it in Nepom= uk.
You can just connect to the required signals when you create the model
and keep the model updated.

Mostly hist= oric reasons. The feeder was written this way sometime ago and I just used = what was there - taking the presence from Nepomuk - to have something worki= ng and ready for testing. It is fast enough; the delay is minimal (~200msec= ). But more and more I'm actually inclining to what you propose, it wou= ld also ease up some Nepomuk activity, which is good I guess.
=C2=A0
Anyway, imho KPeople library should have some initialization method that checks if ktp-nepomuk-feeder is running and fails if it is not (or
perhaps tries to start it before failing). It could also watch its dbus
name and enter some error state when the ktp-nepomuk-feeder disappears.
So when it is in error state you can just return presence-unknown...

Yep, good idea. Noted.
=C2=A0
=
> =C2=A0* starting actions through KTp infrastructure
>
> =C2=A0 =C2=A0 - this is again so we can just switch the models on the = fly and thus
> =C2=A0 =C2=A0 reuse all the existing KTp code paths. However one tiny = issue is
> =C2=A0 =C2=A0 that we don't have account info accessible in the ma= in KPeople
> =C2=A0 =C2=A0 model. I'm thinking

Again I suggest not to keep this in the model, We should have a metho= d
in the library that queries nepomuk directly for the accounts, then
depending on the account type checks which actions are available.
Storing this kind of information on nepomuk is in my opinion useless

Yes, that is all present. Let me rephrase - k= people can start actions solely on its own, but the account id is not in th= e main model to speed up data initialization (it is in Nepomuk) and also be= cause it's needed only for the purposes of starting chat. Currently wha= t happens is that when you double-click a contact, Nepomuk is queried for t= he needed details and then starts an action.
=C2=A0
> =C2=A0* good startup time
>
> =C2=A0 =C2=A0 - currently we're at ~3 secs before contact list sho= ws up with ~800
> =C2=A0 =C2=A0 contacts. I'll investigate where's the holdup an= d see what we can do
> =C2=A0 =C2=A0 about it.

That not good! :P Fix it! :D

Yeah= , but it *is* huge improvement over what it was before :P Still unacceptabl= e though.
=C2=A0
I wonder if we had a DBus service that adds an additional layer between
nepomuk, telepathy, akonadi and the library would improve this
situation. It is an extra layer, but could allow you to save some time
at startup since it doesn't need to be initialized for every program linked to the library.
But then we should also have something similar to TpQt "Features"= so
that the service can avoid connecting to everything when nobody is using it. But then you need again time to initialize the features you need...
Oh well. It was just a random thought.

= I like the features idea. This needs thinking through though - get a list o= f apps that will use kpeople and how, list possible use cases/scenarios and= see if the features would really be helpful or if we should just query for= everything at once. I'm also thinking about lazy initialization - quer= y the basic data needed for display, then do second run where we query for = the data we don't need right away (like contact ids etc). And add them = to the model. It is flexible enough to do that.

--
Mar= tin Klapetek | KDE=C2=A0Developer
--20cf3040ee5e94e9d504d3d2ac81-- --===============7354525519171366849== 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 --===============7354525519171366849==--