I’'ve already mailed the core team about this some time ago, but using the forums gives other users the ability to reply.
The purpose of the patch is quite simple. Right now, Smack only remembers the Resource from with the last Presence was received. With this patch, for each resource the last presence is stored. This way, you can easily get an overview of all the available resources for each user.
Roster.getPresence(user) had to be changed, since there may be quite a few Resources to choose from. Right now, it returns the Presence with the hightest priority. There was some discussion with the core team regarding this, so it might be changed so that it returns the Presence with the highest ‘‘availability’’:
work / away
home / available
In this case getPresence would return the Presence for home, since that one is ‘‘available’’, and work is only ‘‘away’’.
The home resource might have a presence of Available/“Do not Disturb” while work might have a presence of Available/“Chat”. In the current version of Smack, you’‘ll only be able to see the latest presence sent by the server. So if /home comes after /work, you’'d only be able to see that presence and not the “more available” presence value of /work. I believe this patch is meant to address this problem by letting you see all of the presence info about any particluar user from all their different resources.
That part I understand. I now what the patch does. What I ask is, there is a real use in that?
Java it’‘s a language a “bit” slow! If a have a 200 buddy list, each one with two ore three resources, the program may stop when something happens! So the question, it’'s really necessary that patch?
If don’‘t have a real use it only get’‘s the application slower! That’'s not a good trade…
I think it’‘s definitely a useful patch. In almost all cases, you’‘ll want to show the “most available” presence of a user that is logged in with multiple resources. This patch should allow you to do that. I’‘ll have to take issue with the Java is slow comment. In fact, modern JVM’‘s are basically as fast as optimized c code. In any case, I haven’‘t had a chance to carefully look at the patch yet, but we’‘ll make sure the final version doesn’'t negatively affect performance.
XMPP was designed from the start with the concept of different resources under the same user account. Not only can each resource have it’'s own, completely independent presence status, but you can also set the ‘‘priority’’ of each resource. The priority allows the server to decide which particular resource to send a message when the message is sent to the user and not a particular resource. The priority could also be used to show the highest priority presence for a roster item. In some clients this may be more useful since the highest priority resource should indicate the resource the user is currently using (e.g. they may be logged in at home and work, but set the home priority higher when at home).
Well, I suppose there isn’'t much left for me to say now. I agree with iain that the priority should be used to define the resource with the highest availability.
Are there any changes you guys want to see or can it be integrated as it is? If so, please let me know, so I know when to make sure I download a new build.
I have just added the patch to the daily build. I think that it will be available in the next daily build (tomorrow). I also wrote a test case that demonstrates that the modification works fine.