Metacontacts/KPeople status

[Daniele E. Domenichelli]

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.


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


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


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

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.



Cheers,
 Daniele