Why using Nepomuk as a contact store is probably not a good idea

[George Goldberg]

On 21 July 2011 18:34, David Edmundson <david at davidedmundson.co.uk> wrote:
> Yay, an argument on my mailing list.

*your* mailing list? :p

<snip>

> This is the part I'm still stuck on.
>
> Let's pretend I'm a KMail developer and I want to add a feature that
> shows the presence of whoever just sent me an email. A sensible real
> use case. Let's work through what I need to do:
>
>  - I look up the sender's email address and find out a PIMO::Person
>  - I can now find out there presence without any Telepathy stuff at
> all. woo, right?

Yup. Or anything else about them you might want to know.

>
>  - However now I have to write code to turn that presence into an
> Icon, and sensible translated string. Surely this should be in a
> library somewhere, so I advocate the code goes in libKdeTelepathy and
> I link against it.

The idea is that the ontologies provide you with enough information to
do this without needing some KTelepathy library to do it for you. If
they don't then this is a deficiency with the ontologies and should be
fixed. Of course it is also worth remembering that KDE-Telepathy might
not be the only instant messaging application out there, and therefore
if any other KDE application wanted to benefit from the same
application level integration, they just have to store stuff to
Nepomuk too.

>  - To do something useful like start a chat, I have to link against
> TpQt4, find the actual telepathy contact and ensureTextChannel().

Note that displaying stuff is also useful, but I take the point anyway.

>
> At which point, I've just used KDE Telepathy and TelepathyQt4 anyway,
> so surely I (or telepathy-kde) may as well have just looked up the
> presence directly.
>
> NOTE: I'm not saying we don't need nepomuk to bridge the two
> components etc., as it needed it to find out info from PIMO::Person,
> simply saying it may as well just store the AccountPath, and ContactId
> - and the name/avatar for metacontact joining purposes.

Well, then you miss out on read-only access to all the other stuff.
There are plenty of things that you might want to do with access to
this data without actually starting a chat.

>
> Why does the tp-nepomuk service write out
> capabilities/presence/blockStatus/publishStatus/subscriptionStatus,
> and client code (via ktelepathy or not) read it back? You only know
> how to do anything with it if you are using telepathy - and are going
> to write telepathy specific code anyway and/or use ktelepathy. At
> which point ktelepathy may as well look it up in real time from tp
> itself.

None of those are written to Nepomuk in a Telepathy specific way.

Also, to address your point directly, an example of one of the *flying
car future* ideas that may come out of Nepomuk some time soon is a
generic framework for performing actions on resources, sort of like an
ontology to allow apps to let the user perform relevant actions on
different classes of resource (e.g. People) without having to link
directly to the library that enables those features. This of course
would make initiating chats and other actions possible within
applications that have no awareness at all of KDE-Telepathy.

In summary - yes of course we could just store accountId/ContactId
pairs, but since there are plenty of uses for all the other
information, why not also store it?

>
> ---
>
> Whilst I'm here say I have a KTelepathy::Contact, there's no method to
> get a contactId or TelepathyQt4::ContactPtr - at which point I can't
> actually do /anything/ with the nepomuk contacts I have.

I understand and I'm aware of that. telepathy-kde is not complete yet,
so let's keep this point out of the debate.

--
George