On 1 April 2011 12:39, Francesco Nwokeka <[email protected]> wrote: > On Friday 01 April 2011 13:17:27 George Goldberg wrote: >> On 1 April 2011 12:06, George Kiagiadakis <[email protected]> >> wrote: >> > 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? >> >> 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 _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
