loadRosterOnLogin has non-trivial side effect on getRoster

getRoster() is automatically called on login unless loadRosterOnLogin is set to false. However getRoster triggers a reload of the roster if loadRosterOnLogin is set to false. This means that 2 calls to getRoster cause no aditional network traffic when loadRosterOnLogin is set to true and two roster fetches otherwise. The impact of loadRosterOnLogin on getRoster is counter intuitive, makes optimizations hard and is not documented.

Steps to reproduce:

• set loadRosterOnLogin to false

• call getRoster

• call getRoster

Expected result:

• the roster engine is initialized uponfile:///home/treffer/work first getRoster

Actual result

• The roster is loaded twice

Possible solution:

• use roster.rosterInitialized to determin the state of the roster engine

• trigger a roster load if needed

• don't use loadRosterOnLogin after login

This may require apps insisting on the reload logic to do a manual "reload" after getRoster. However it's unlikely that apps do it via getRoster() (as you have events and a reload method).

The trivial patch for this would be http://github.com/rtreffer/smack/commit/59352e14227f9f433478a7fe53556c7dc94f9d11