Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

MF1-MS
Copy link
Contributor

@MF1-MS MF1-MS commented Aug 17, 2022

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.

Treat resources belonging to the logged in user as being in the roster, so clients are informed about presence changes on the same account.
@Flowdalic
Copy link
Member

Flowdalic commented Mar 18, 2023

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 Roster. Then, let Roster hook into the connection authenticated callback (if not already), and register the stanzas listeners with the now known JID of the user.

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.

@MF1-MS
Copy link
Contributor Author

MF1-MS commented Apr 24, 2023

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.

@Flowdalic
Copy link
Member

In what circumstances do we not know the logged in user's JID?

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 ConnectionListener.authetnicated(), despite its name, runs after the resource has been bound. So we can use that callback, as I wrote in my previous comment.

@MF1-MS
Copy link
Contributor Author

MF1-MS commented Apr 26, 2023

So to rephrase what you suggested for my understanding, create a ConnectionListener for Roster then when triggered for authenticated() constructs a StanzaListener containing the now known Jid and adds it to the connection. But wouldn't having a separate StanzaListener like this lead to a lot of code duplication with the existing PresencePacketListener?

@Flowdalic
Copy link
Member

Sorry for the late reply. But thanks for your contribution.

I came up with #642 as alternative, which I would currently prefer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants