On Fri, Apr 1, 2011 at 1:56 PM, George Goldberg <[email protected]> wrote: > On 1 April 2011 11:52, Olli Salli <[email protected]> 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? _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
