Adding/Approving/Removing Contacts

[Olli Salli]

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

On 01.04.2011 14:06, George Kiagiadakis 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?

Depending on how long that "before" period might be, I think a viable
short-term solution could be to require the contact list to be launched
to show those requests, and using the logic I outlined above, show any
requests which were missed while the contact list wasn't active when it
is finally started again.

This is of course slightly misleading from the user experience POV, as
it promotes the contact list as a more central piece than it actually
is. I don't think this is a big problem, as you aren't trying to emulate
the final UX anyway in the short time period during which you don't use
nepomuk, I guess?

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

iQEcBAEBAgAGBQJNlbSlAAoJEAQQkupGanj4JbQH/Rm9/U5+YH8rmswf7rHORWRB
39RD2n5KnENVh/gBwXre4wl+t+F4MpGPCX2YevPdYF24VUBcIrRalJY+kWMJcq+b
xUL9GoDG0bAcW4H6KYlWIEfMbDyRhH3V2HFrybXkvUSTntoK8Nwg7wW9SOS3vu4Y
1pgUp9fIJlXNysQLA1YI/Z1QhQgNeupugitdJpY7J4mvN4am6uQev0eXPDrfM0AM
JPYPYY9p0nCKFE2EPsgU9lk3zejpZWJUGvpbX5wONsVDpz8B5OVNAOQHY3OmACnt
jdhAyG/TcMWYWb7SEB7snzQlsxDHtaJz4Oakyun5od0eaWYBw2hiPEvErXeRaDE=
=Kzyd
-----END PGP SIGNATURE-----