-
Notifications
You must be signed in to change notification settings - Fork 887
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inform ourselves of presence info. #538
base: master
Are you sure you want to change the base?
Inform ourselves of presence info. #538
Conversation
Treat resources belonging to the logged in user as being in the roster, so clients are informed about presence changes on the same account.
I am skeptical about this one, as this makes the roster behave differently depending on if the user's JID is known or not. I can see that such a functionality would be desirable though. I wonder if we shouldn't take a different approach on the design though. I would probably experiment with an design where there are dedicated callbacks for presence changes from other devices of the user, that can be requested from the I am not yet decided if those "own presence changed" callbacks are also invoked for presence changes of the local connection. From an UI perspective it may be beneficial? That said, I am not sure if the protocol does reflect the presence back to self. Need to look that up in the spec. |
In what circumstances do we not know the logged in user's JID? I can't find anything specifically on the matter in the base XMPP RFCs or XEP-0162. But that means I can't fid anything that argues this would be spec-uncompliant either. |
That depends on your definition of "logged in". In XMPP you do not know your JID after you authenticated (cf. RFC 6120 § 9.1.2). Only after you bound a resource the client becomes aware of its own JID (cf. RFC 6120 § 9.1.3). Note that Smack's |
So to rephrase what you suggested for my understanding, create a |
Sorry for the late reply. But thanks for your contribution. I came up with #642 as alternative, which I would currently prefer. |
Treat resources belonging to the logged in user as being in the roster, so clients are informed about presence changes on the same account.
This MR adds the above function and two UTs to check the existing behaviour of the
Roster.contains()
, and verify the new function.