Adding/Approving/Removing Contacts

[George Goldberg]

On 1 April 2011 12:39, Francesco Nwokeka <francesco.nwokeka at gmail.com> wrote:
> On Friday 01 April 2011 13:17:27 George Goldberg wrote:
>> 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
>
> (stupid)Question: what about those users which don't use nepomuk? How will this be handled?

Nepomuk is (will be) a hard dependency of KDE-Telepathy (although,
that doesn't mean you have to use things like strigi indexing - this
can be disabled separately).

--
George