Adding/Approving/Removing Contacts

[George Goldberg]

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 :)

--
George