[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-telepathy
Subject: Re: Metacontacts/KPeople status
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2013-01-21 20:54:27
Message-ID: CAPLgePpWMS=7bqq==P7cwGfHUBjz9Z5_iLh3c0gGm-r+N-39CQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
On Mon, Jan 21, 2013 at 11:00 AM, Daniele E. Domenichelli <span dir="ltr"><<a \
href="mailto:daniele.domenichelli@gmail.com" \
target="_blank">daniele.domenichelli@gmail.com</a>></span> wrote:<br><div \
class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On 21/01/13 08:54, Martin Klapetek wrote:<br> \
> * contact's offline presence<br> ><br>
> - for the contact list to work properly with kpeople, one needs to<br>
> have the ktp-nepomuk-feeder running ALL the time. Once it's down,<br>
> we're screwed. Currently there's a different problem though - \
when<br> > the service shuts down (logout or reboot for example), it leaves \
all<br> > the presences in Nepomuk in whatever state they were. This \
means<br> > when you relogin and run the contact list, all the contacts \
have<br> > wrong presences until the feeder kicks in and puts correct data \
into<br> > Nepomuk. If the feeder for whatever reason won't start, the \
user is<br> > left with random invalid presences. It could write offline \
presence<br> > while being destroyed, but that would need to be synchronous \
job<br> > which can take some time, which means delaying<br>
> reboot/logout/whatever for no apparent/visible reason to the user.<br>
> We were talking if we could reuse KTp presences as we have them<br>
> available in almost realtime, but that means combining two models<br>
> (where one queries the other) and I don't like that very much.<br>
<br>
</div>This is something I've been wondering for a while... why should we have<br>
the presence in Nepomuk, when we can just query telepathy?<br>
We can have a method _in the library_ that returns you one presence for<br>
your metacontact, but it doesn't mean that we need to store it in Nepomuk.<br>
You can just connect to the required signals when you create the model<br>
and keep the model updated.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> Anyway, imho KPeople library should have some \
initialization method that<br> checks if ktp-nepomuk-feeder is running and fails if \
it is not (or<br> perhaps tries to start it before failing). It could also watch its \
dbus<br> name and enter some error state when the ktp-nepomuk-feeder disappears.<br>
So when it is in error state you can just return \
presence-unknown...<br></blockquote><div><br></div><div>Yep, good idea. \
Noted.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> * starting actions through KTp infrastructure<br>
><br>
> - this is again so we can just switch the models on the fly and thus<br>
> reuse all the existing KTp code paths. However one tiny issue is<br>
> that we don't have account info accessible in the main KPeople<br>
> model. I'm thinking<br>
<br>
</div>Again I suggest not to keep this in the model, We should have a method<br>
in the library that queries nepomuk directly for the accounts, then<br>
depending on the account type checks which actions are available.<br>
Storing this kind of information on nepomuk is in my opinion \
useless<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div class="im"> > * good startup time<br>
><br>
> - currently we're at ~3 secs before contact list shows up with \
~800<br> > contacts. I'll investigate where's the holdup and see \
what we can do<br> > about it.<br>
<br>
</div>That not good! :P Fix it! :D<br></blockquote><div><br></div><div>Yeah, but it \
*is* huge improvement over what it was before :P Still unacceptable \
though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I wonder if we had a DBus service that adds an additional layer between<br>
nepomuk, telepathy, akonadi and the library would improve this<br>
situation. It is an extra layer, but could allow you to save some time<br>
at startup since it doesn't need to be initialized for every program<br>
linked to the library.<br>
But then we should also have something similar to TpQt "Features" so<br>
that the service can avoid connecting to everything when nobody is using<br>
it. But then you need again time to initialize the features you need...<br>
Oh well. It was just a random thought.<br></blockquote><div><br></div><div>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.</div>
<div><br></div></div>-- <br><div><span style="color:rgb(102,102,102)">Martin Klapetek \
| KDE Developer</span></div>
_______________________________________________
KDE-Telepathy mailing list
KDE-Telepathy@kde.org
https://mail.kde.org/mailman/listinfo/kde-telepathy
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic