I am currently testing my Smack client.
I have set the subscription type set to MANUAL. Upon an incoming Presence message with a Type of SUBSCRIBE, I open up a window informing the user that another user is tyring to add them as a buddy with the option of Authorizing or Denying the change.
However, before the user has a chance to respond, a rosterModified event is fired.
Is this the correct behavior?
Currently, I have a RosterListener that updates the displayed user roster on modifications, so a request results in an immediate update of their visible buddy list.
Any help/advice is appreciated.
-Ken
No, this is not the correct behavior. But this may be related to the issue i posted here:
http://www.jivesoftware.org/forums/thread.jspa?threadID=15606&tstart=0
Are you by chance using Jive Messenger?
And could you post the packet trace from the smack debugger?
I’'m using Jive Messenger v. 2.1.5.
Here’'s a look at the packet I recieve from the GAIM client:
Maybe Matt Tucker could shed some light on this, as he wrote the Presence packet class?
-Ken
could you post any packets before and after that that you receive?
These packets were the result of adding one buddy to the GAIM client, who shows up as offline in my client. He shoudln’‘t show up at all in my client, but since he does, shouldn’'t he show as online?
Sent[/b]
Recieved[/b]
well you are sending a subscribed packet which causes your roster to be modified.
In other words the server changes this:
/code
to this:
/code
I actually did send that SUBSRIBED packet at the end on purpose.
The problem is, before I send that packet, I get a rosterModified event (and my roster is indeed changed) which causes my buddy list to display the requester as offline.
Once I ‘‘Authorize’’ the requester, and add him to a group in my roster, he shows up correctly.
If I ‘‘Deny’’ him, which means I send nothing back, then he remains as a ghost on the top level of my roster.
Should I be sending some sort of Presence packet back to him upon a denial?
-Ken
So if you don’'t send the subscribed packet are you still receiving this packet:
/code
Below is the last IQ packet I get after the GAIM user requests to add a buddy (before I authorize him to add me):
When I update the display of my roster, I could check for subscirption types and only display those that are of Type BOTH, TO, or FROM. I’'m not sure if this is the correct solution.
I guess I’‘m tyring to figure out whether Jive Messenger is in fact sending the correct packets and I’'m just not interpreting them correctly.
-Ken
You in fact have reached the same bug with Jive Messenger that I have. From the RFC pages 34-35 http://www.ietf.org/rfc/rfc3921.txt:
If the contact has a connected resource “it MUST deliver the subscription request to the contact (if not, the contact’‘s server MUST store the subscription request offline for delivery when this condition is next met; normally this is done by adding a roster item for the contact to the user’'s roster, with a state of “None + Pending In” as defined under Subscription States (Section 9), however a server SHOULD NOT push or deliver roster items in that state to the contact).”
This particular passage doesn’'t apply in your situation as the user sending the subscribe was in your roster at the beginning of the session. But, you should still not be getting a roster push.
Hey Alex,
After carefully reading the paragraph that you cited I now see that JM is sending an incorrect IQ packet to the contact with status “none”. Is this what you reported in this issue JM-384? In that issue I understood that it was a presence packet problem and not an IQ packet problem. If this is another issue then I will create a new issue, otherwise I’'m going to change the existing issue to describe this case.
Thanks,
– Gato
Gato,
That is in fact the problem…an IQ packet of Type set are forwarded to the user. I read the JM-384 issue you referenced, which is exactly the problem. The server is incorrectly forwarding a message to the client which is causing a rosterModifed event.
For the time being, I may check each RosterEntry’'s RosterPacket.ItemType and simply not display those with type NONE. Do you see any problems with that idea?
-Ken
Hey Gato,
I might have explained the problem wrong but Kenneth did a good job of just explaining it. It seems like all types of presence packets, at least subscribe and subscribed, improperly cause a roster modification. I think JM-384 does in fact apply hear, though perhaps it could be worded a little differently.
Thanks as always,
Alex
Hey Ken:
Checking the roster type of the packet does seem like an appropriate solution for now.