KDE Telepathy Nepomuk questions

[Olli Salli]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03.04.2011 14:21, George Goldberg wrote:
> 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

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

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?

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?

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?

and if so

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?

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

iQEcBAEBAgAGBQJNmFwUAAoJEAQQkupGanj4FGIH/3ekqwBfPjy2y99+3Dax66JB
I3PR2KCOf2cn8T9bEpwtS4aJtof692vy5kc64BZV2Zc4pmpgh2JaqFc+SgIM5UgM
KK73c6T34PSv5lfxGVk4Znj8GNHTQRFnjaixZgX6uq72e+5OxNl4SnLYYZascKef
u9xJneSdSxz8Up7dm3iG9AQWtnDgKkJvTezAYS7BhWjgBZgCQwtR7Iv2J9fJ+pXH
wnoD+I4L914r6zA6dQXGh7XlW6yL1L2/1dqq93cJQQOw9dnyMbYQg64l78b+xC1+
b65qx+XwZwyW7ysodjPuI/Dx6Wgjcq+yvnLfED5Suv5ajM3wvY1J2HJhxB9U+4Y=
=Ke2c
-----END PGP SIGNATURE-----