KDE Telepathy Nepomuk questions

[Olli Salli]

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

Br,
Olli
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNmFRkAAoJEAQQkupGanj44toH/1MOEUAMB5GhzGx2oM0fQ2Px
PedE5GytvWWFI0A7MJh+E86GB7f2dO15T+X3MAflWqKJ3e8QAuoY2ZV1xDNBocwI
FwZ7/mok8SgzSCir5enSQY+RPt6zWM6aARckfQwhBO1KOP4ExRpAGpgNIXLVbSeG
UnqQ6LCDVEWnKZDA4fy2KJbK4J/xAHnxTF5aebZCVygQEi84sm7b0WUFXPnni1hD
rMtFzLvxIq6m6uAfzWIh5Lyt6E7TZfXR5M0pOU3F8p8OdF12LeD5hpvviZMQg+QX
u4JCaR0sacniNMGsYfqUZu2mZqzjChhiMfQSLnnWbxo5vUIS+92FUB1j+ZdzIGQ=
=XNd4
-----END PGP SIGNATURE-----