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

[David Edmundson]

2011/7/21 Martin Klapetek <martin.klapetek at gmail.com>:
>
> On Jul 21, 2011 7:52 PM, "George Goldberg" <grundleborg at googlemail.com>
> wrote:
>>
>> 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.
>
> My vision of this a dbus connection. You simply send contact id over dbus
> and some listening service will call the ensureTextChannel() for you. Since
> you'll have the presence info in the first place, it means that Telepathy is
> up and running, so the PIM does not have to create the channel at all, in
> fact, it's not important who creates the channel. So you won't need to link
> against ktp and write tp code inside PIM.

Well this would make no sense on multiple accounts:

1) You completely trash the point of any abstraction (which is George
G's reasoning for doing any of this), as you've just put in telepathy
specific code.

2) no-one writes app code that talks to dbus directly (it's fugly,
prone to breaking and you'll get told off for doing it), so it gets
written into a library - but we already have a library that calls
ensureTextChannel with a contact Id.... it's called TelepathyQt4.

The only thing this method does is save you linking against a lib -
but there's nothing wrong with linking to libs.

What I think George was saying the long term future plan is for
nepomuk to have some some (again super abstracted) way for clients to
tell nepomuk to do things without using telepathy terms, then nepomuk
will call a reverse telepathy-nepomuk-service.

Personally, I think that's a rubbish solution too, but I'll reserve
judgement on that till nothing happens I roll something better.

>
>>
>> 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().
>
> No need to as posted above.
>
>>
>> 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.
>
> Once done, the dbus solution posted above is at hand.
>
> --
> Marty K.
>
>>
>> --
>> George
>> _______________________________________________
>> KDE-Telepathy mailing list
>> KDE-Telepathy at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
>