powered by Jive Software

Bug in Smack 3.0.4 Presence code

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:

<presence to="macro10.com@gmail.com" from="matt.heimer@gmail.com/GaimF4BD32D0">
<show>away</show>
<c xmlns="http://jabber.org/protocol/caps"></c>
<x xmlns="vcard-temp:x:update"><photo>3e0caaf1070f10b7a038487517d4e147cc2f5b11</photo></x>
</presence>

And here’s what the same client sends when setting the status to available. Notice the lack of a <show> tag.

<presence to="macro10.com@gmail.com" from="matt.heimer@gmail.com/GaimF4BD32D0">
<priority>1</priority>
<c xmlns="http://jabber.org/protocol/caps"></c>
<x xmlns="vcard-temp:x:update"><photo>3e0caaf1070f10b7a038487517d4e147cc2f5b11</photo></x>
</presence>

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.

Bump.

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.

bump

Well, the XMPP standard says

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?

There is no such thing as availability is assumed when no packet type is provided.

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.

The bug won’t be fixed because the code that people like myself have had to add in as a work around will no longer function? Seriously?

If you do leave it broken then yes, please update the Javadocs to correctly document this behaviour.

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.

The behaviour should be to return Mode.available. It’s not my option, that is the stated behaviour as outlined in the XMPP rfc. See: http://www.xmpp.org/rfcs/rfc3921.html#rfc.section.2.2.2.1

The relevent text is: “If no <show/> element is provided, the entity is assumed to be online and available.”

So then this is what you have, assuming the changes you want are made:

the packet Smack receives:

<presence type="unavailable" from="user@example.com" />
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.

It appears that I jumped the gun, notice the qualification on in the previous section:

from http://www.xmpp.org/rfcs/rfc3921.html#rfc.section.2.2.2

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?

Bumping again.

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.

Oh and “bump” again.