Adding/Approving/Removing Contacts

[George Kiagiadakis]

On Fri, Apr 1, 2011 at 1:56 PM, George Goldberg
<grundleborg at googlemail.com> wrote:
> On 1 April 2011 11:52, Olli Salli <olli.salli at collabora.co.uk> wrote:
>
> <snip>
>
>> 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.
>
> I'm convinced :)

Me too, but what do we do before we have a working nepomuk service?