Adding/Approving/Removing Contacts

[Olli Salli]

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

On 01.04.2011 13:00, Dario Freddi wrote:
> On Thursday 31 March 2011 22:53:26 David Edmundson wrote:
>> One of the outstanding features left before our first release is the adding
>> and approving of contacts.
>>
>> The main issue is the "who (which component) is responsible for doing
>> this". I want to discuss this on the ML as I don't feel enough stuff is
>> being discussed/announced at present.
>>
>> I think "add contact" should go in the contact list, as it makes sense to
>> open that to alter your contacts. Same for removing them.
>> (I have a patch for this, waiting on Martin's merge)
>> In future we have DrDanz's KJobs for doing this all with all the nepomuk
>> jazz, and my "add user dialog" could be made shareable.
>>
>> The issue is "approving contacts" (or to use the correct term
>> presencePublicationRequested) when someone else adds you. Telepathy is
>> always running and you may be signed in regardless of whether you have the
>> contact list open. In this happens someone needs to notify the user of this
>> event.
>>
>> I was discussing with George K that this should go into the approver, it's
>> always running all the time and communicates via KNotify. It seems a
>> sensible choice (even the name fits)
>>
>> Does anyone object to adding this functionality into the KDE approver?
> 
> Makes sense to me

I'd actually put it to the nepomuk service, though the approver would
probably work as well as long as it can access the nepomuk storage
sufficiently. Why doing it in the nepomuk service might be cleaner
becomes more evident once you read the answer below

> 
>>
>> @Telepathy-Qt4 people:
>> What happens if everyone ignores the presencePublicationRequested() signal,
>> and no-one calls authorisePresencePublication or anything? Is the incoming
>> request lost forever?
> 
> I think this really boils down to the CM (maybe Olli or Andre can tell you 
> more), but I suppose everytime the CM connects, it would stream the request 
> again.

The presence publication requests, as all other parts of the roster, are
fully state-recoverable. presencePublicationRequested in particular
signals that there is now a contact in allKnownContacts(), which has its
publishState() set to Ask. (They ask for you to publish your presence to
them, i.e. permission to see your presence). However, don't assert on
that or anything, because that would be racy: somebody else might have
approved or rejected the request already, or the contact might even have
rescinded their request - in which case you shouldn't actually show your
dialog.

Thus, in addition to listening to presencePublicationRequested(), you
should check the initial state after connecting to it, by looping over
allKnownContacts() and checking for any state = Ask contacts. These
would be in particular contacts that previously requested your presence,
perhaps when you were offline, or when you were connected to the account
earlier (maybe even with another client), but didn't approve or reject
the request then.

You can also recover the request message by using
Contact::publishStateMessage() in recent-ish tp-qt4 versions, on
protocols with such a concept anyway.

Now, always showing "hey, this person wants to be your friend" again and
again when you reconnect to the same account, if you chose to ignore
their request earlier, is obviously annoying. Thus, you need some kind
of local state to mark contacts as "I've seen their request, and
notified the user. I don't need to bug the user again unless they
actively want to reconsider people whose requests they've previously
ignored".

I implemented that annoyance prevention in the Kopete Telepathy protocol
plugin by immediately committing the new contacts discovered thus as
Kopete contacts, but showing them as "pending" and enabling context menu
actions to later approve and reject their request. I wouldn't then show
additional request dialogs even if the Telepathy contact was discovered
to be in publish state Ask, or getting a presencePublicationRequested
signal, until the Kopete contact had left the "pending" state one way or
another.

This is where nepomuk comes in. Whichever component listens for incoming
friend requests must record seeing a request somewhere. In your case it
would be most natural to store this in Nepomuk along with the other data
for that contact. Now, you could do this in the approver, yes, but
wouldn't that obfuscate the data flow a bit, with the approver in
addition to the nepomuk service trying to insert new contact data into
nepomuk? (Would that even be possible to do safely?)

Notably, the nepomuk service is already probably listening for changes
in allKnownContacts() on all connections, and doing similar initial
syncs of the contact list state in general when picking up new
connections. Handling the friend requests would therefore fall there
naturally from the Telepathy point of view.

> 
>>
>> Dave
> 
> 
> 
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy

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

iQEcBAEBAgAGBQJNla5iAAoJEAQQkupGanj4AFAIANL9Y4dXZsIPv3p1K6fJUvU7
Nd4G/+bD5GoxdPlWKdBuO/Di4MFS0NoB/ETvrMngKSswqzg3kDN90hwtEocjIVI8
yQqv0/7uWgj38a/bLZtYOdSec+TjTkpH13F22TqA+c5Hq+E9IHd7rYaQQ6cTwkPW
oczaHYjZP5i4XyYZ/jH/qf2C2lqtlTCX5sYD15TFYqaLYmow47esKme+XXvqG2jW
9Boj0i7BQRQ4+rhLPTdm9eEzYTjI9t+vej2bAiUkQLGnhm32n39bHA39xKaKwuhl
PohDT8nl0+tuNKr2pqcsCZ4mhqZQ6MwZ14xXVrHQc0fgacH+mJZvqUO5tAyGK38=
=3e+A
-----END PGP SIGNATURE-----