KDE Telepathy Nepomuk questions

[George Goldberg]

On 3 April 2011 12:37, Olli Salli <olli.salli at collabora.co.uk> wrote:
> I'm sorry that I didn't investigate how this is currently handled in KDE
> Telepathy - I was under the assumption that this hadn't yet been
> implemented as generally our nepomuk interaction is said to be "not
> there yet".

My bad. To clarify that - the infrastructure is there (although not
yet release quality), and the first release is going ahead without it
simply because we'd like to get something released soon, and the
Nepomuk stuff is holding things up (entirely my fault).

> Could you really, really briefly summarize your solution in the
> following key aspects:
>
> 1) is it so that there is a base notion of presence in NCO/PIMO and you
> have extended it so that the specific Telepathy presence can
> additionally be received?

Yup. The Nepomuk NCO ontology stores a presence string and a presence
message. Any app should understand these. The Telepathy ontology
extension has a field for presence type (can't remember the name)
which stores the enum value from Tp. This allows telepathy aware apps
to have all the available information from a Telepathy SimplePresence
property.

> and if so
>
> 2a) how is the "I don't know anymore" presence invalidation issue
> handled? does the presence disappear, or does it go to some "unknown"
> value in all of the (extended) levels of presence stored?

Presence state becomes unknown (in all appropriate Nepomuk properties).

> and
>
> 2b) do you intend Nepomuk to be the only presence source, even for
> Telepathy aware applications in KDE, so that all presence updates are
> transferred through Nepomuk storage to consumers?

For applications aware of Persons (our metacontacts) yes. When we are
dealing with just the presence of a particular Contact (KDE-Telepathy
language - think raw Contact, rather than part of a Person), then not
necessarily.

> 3) is it really considered efficient enough (say, by Nepomuk upstream)
> to store there the presence updates of potentially thousands of
> contacts, which can happen really often because of auto-away and
> auto-idle features?

unscientific tests (as in, my experience so far) suggests that there
are not going to be significant performance issues. Theoretically,
upstream would say that performance should be fine too. In practice,
I'm hoping to do some more scientific tests (with the #ubuntu test
case and similar extremes) once I'm back to hacking properly. If these
tests do demonstrate a performance issue, then we'll try and solve it
with the Nepomuk developers help. If that fails, then it will be
necessary to look again at ways of bypassing Nepomuk for very
transient data. However, my experience so far suggests that things are
not very likely to be that disastrous. I'm well aware of the problems
that people have had with tracker in a similar context, but happily
things aren't nearly as problematic in Nepomuk land :).

Hope this helps a bit.

--
George