In the Javadocs for the Presence class it states that the default Presence.Mode should be Mode.available. I take “default” to mean that when no other Mode is set then Mode.available will be the value returned. However when no mode is set on an incoming presence packet a value of null is used instead. The Javadocs for Presence.java indicate that mode may not always be sent but this case doesn’t seem to be handled in code.
Here is an example of an “away” presense packet that originated from a Pidgin(formerly Gaim) IM Client:
Either Presence.java needs to be modified to return Mode.availabe when mode == null or util.PacketParserUtils needs to set the mode to available when no <show> tag is present.
I’m going to keep replying to this thread to keep it on the first page until a developer either fills a bug report for me or tells me that this was a deliberate design choice.
On a somewhat related note; Using the forums for bug reporting is really stupid. It’s too easy for the developers to get busy and miss a critical thread. There is no reason the community shouldn’t be able to file bug reports directly that way the devs can run a report at any time to make sure that nothing gets missed.
The ‘type’ attribute of a presence stanza is OPTIONAL. A presence stanza that does not possess a ‘type’ attribute is used to signal to the server that the sender is online and available for communication. …
So Mode.availabe really should be returned instead of null. I thought maybe it was a design choice but if that’s what the XMPP spec says then there is no question about it.
Can a Jive developer please fill out a bug report?
But what I’m saying that it is NOT assumed in Smack like it should be. Presence.getMode() should NEVER, NEVER, NEVER return a null value. It currently does because the code that parses the presence packet (util.PacketParserUtils) does not set the mode when the <show> tags are missing from a received presence packet.
This is a bug receiving a presence packet, not sending one.
I can agree with your view point but I think that this is one of those things that won’t change as it would require anyone who expected null to represent available to change their code. If they don’t it may cause unexpected behavior. That being said I can update the JavaDocs if you think what null returned from this method represents.
It should be noted that getMode correctly states the behavior:
Returns the mode of the presence update, or null if the mode is not set. A null presence mode value is interpreted to be the same thing as Presence.Mode.available.
What should be the behavior in your opinion of the type is Unavailable? Should getMode return Available? Now, that would be confusing to implementors as well IMHO.
Presence.Type type = presence.getType();
// type is Presence.Type.unavailable Presence.Mode mode = presence.getMode();
// mode is Presence.Mode.available
Seems like the RFC is incorrect, I will send a message to the XMPP standards mailing list as this is not the case where the user is online and available if there is no show.
If the presence stanza possesses no ‘type’ attribute, it MAY contain any of the following child elements (note that the child MAY be sent in a presence stanza of type “unavailable” or, for historical reasons, “subscribe”):
So it says show is not always available, I return to my previous query, what should be returned if you have getType of UNAVAILABLE and no show? Should getShow return available?
Message was edited by: Alex Wenckus
Correction of place in the RFC and the correct wording from the RFC
Ok I see your point so I’ll amend my request. If getType returns AVAILABLE then getMode should not return null. The rfc describes <show> as “specifies the particular *availability *status”. So under some cases getMode would return null when a <show> tag is missing but not in all cases as it’s done now.
Look at my first post and see the presence packet that GAIM/Pidgin sends out to indicate that the user is available. Given that the packet seems to be in-line with the RFC, should there be any reason that Smack gives me a null for the mode when recieving that packet?
A similar argument can be made for the ‘type’ field of the org.xmpp.packet.IQ class (Openfire, not Smack). The Type field cannot be null. It can only be one of four values (get/set/result/error). The org.xmpp.packet.IQ implementation does allow for null values though. I think it should throw IllegalArgument- or -StateExceptions instead.
Smacks IQ implementation ‘solves’ this by replacing null with ‘get’. Throwing an IllegalArgumentException or IllegalStateException instead would seem a bit cleaner to me, but hey, I can live with the current implementation.
I wouldn’t mind an Exception in place of a null either but only when there was no valid state that should be returned. I just want available returned when it should be.