KDE Telepathy Nepomuk questions

[George Goldberg]

On 3 April 2011 12:05, Olli Salli <olli.salli at collabora.co.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03.04.2011 13:35, George Goldberg wrote:
>>>> ---
>>>> Despite the line "although applications can access the Telepathy data
>>>> directly from Nepomuk" I didn't see any interface to do that (is it just not
>>>> done yet). For me it's quite a big thing, we should never try to "abstract
>>>> telepathy" so you can't reach it, only add layers on top for UI and
>>>> metadata.
>>>
>>> It's called the Nepomuk API (in kdelibs). There is no Telepathy
>>> specific API because, again, the entire point of applications being
>>> able to access data direct from Nepomuk is for those apps which don't
>>> know or care about the existence of Telepathy (e.g. KMail).
>>
>> Clarifying this a bit: These applications would be interested in the
>> particular data we (Telepathy) have stored, but do not need or want to
>> be aware of the fact that it is Telepathy that is doing the storing,
>> or the Telepathy APIs. E.g. KAddressbook might want to display the
>> presence status of the people in the addressbook, but in order to do
>> this, should not have to be aware of KDE-Telepathy or use our APIs. It
>> can just get this data with an ordinary Nepomuk query on
>> nco:IMAccounts and their associated properties.
>>
>
> In which format exactly would the presence be stored, though? I believe
> you either need to
>
> 1) define a nepomuk abstraction (schema?) for presence (or is there one
> already?), and use that, flattening the Telepathy presence to it
>
> The actually Telepathy-aware applications would then be better off by
> just looking directly at the presence Telepathy reports, because then
> they'd get the exact presence. In particular, even if the nepomuk
> presence abstraction would e.g. match the broad presence categories (the
> enum presence type) of Telepathy, profile files make it possible to
> define how to display (logo, localized display name) custom protocol-
> and/or service-specific presences. Thus, telepathy-aware applications
> can use the Tp::Profile API in tp-qt4 to display the exact
> protocol-specific presence.
>
> 2) save it as the raw Telepathy presence, essentially the (string id,
> enum broad category, optional string status message) triple that has
> confused even us so many times
>
> Well, this would mean that the non-Telepathy-aware applications couldn't
> really use the presence, because they don't understand it at all. They'd
> have to gain some level of Telepathy-awareness to be able to interpret
> the string and the enum sensibly.
>
> Thus, I'd go at most for a hybrid approach where we offer the nepomuk
> presence feed with a simple nepomuk presence abstraction to
> non-Telepathy aware users, but use Telepathy presence directly (received
> from the CMs using tp-qt4, because we probably don't want two different
> representations of the same presence in nepomuk) in all KDE Telepathy apps.
>
> Format issues aside, it is also questionable to store transient data
> like presence to a persistent store like nepomuk, or equivalently
> tracker (that has been done, with disastrious performance consequences).
> When you are online, applications can receive the up-to-date presence of
> contacts directly from Telepathy, as long as they're Telepathy-aware.
> When you aren't, any presence you previously stored to nepomuk isn't
> really valid anymore.
>
> Now, in my hybrid approach, where non-Telepathy aware applications could
> get abstracted presence from Nepomuk, the performance and validity
> issues apply because we'd still update nepomuk all the time whenever
> somebody's presence changes (and not update it, when the Telepathy
> accounts are offline, an artifact of the state of the world which the
> non-telepathy aware application doesn't understand!). Would it perhaps
> be better to offer some really simple API to get a Person's aggregated
> Telepathy presence in the KDE Telepathy library? So applications which
> want to gain such presence display support could become sufficiently
> Telepathy-aware to do so, by using a really, really minimal library API,
> without the problems.
>
> I believe similar consideration should be done for other data
> stored/offered in Nepomuk, besides presence.

I'm sorry Olli, but this is way too much for this thread - let's just
say I spent most of the last three years dealing with exactly these
issues, in conjunction with the Nepomuk and upstream Telepathy
developers. I'd really rather not go back through the entire thing
again right now (if you do want to discuss it all again, I can oblige,
but not until after my exams in May). Suffice it to say that I have
already run into all these problems you highlighted (and many more),
and I believe the solution we currently have is the best (and only
workable one). I suggest taking a look at how the Nepomuk ontologies
work (particularly the NCO, PIMO and our extension ontology in the
telepathy-nepomuk-service repo) to see how the data issues with
presence and so on have been handled.

--
George