Adding/Approving/Removing Contacts

[George Goldberg]

On 1 April 2011 12:06, George Kiagiadakis <kiagiadakis.george at gmail.com> wrote:
> 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?

Ah good question... Since the first release is going to be
nepomuk-free we need to do something temporary. Perhaps it could
temporarily go in the contact list app for the first release, and then
in the summer when we are fully nepomuk enabled it can move to the
nepomuk service permanently?

--
George