I have an ejabberd server running perfectly on Windows 2003 Server.
I am utilizing a shared roster so that all new users see @all@ registered users.
New users registering from a fat client (PC, laptop - etc) have no problems.
New users registering from a thin-client (server based computing Citrix environment) encounter the following issue:
When the user logs in for the first time every user on the shared roster is shown as “Offline”. Once a user goes Offline and then comes back Online they are shown as “Online”.
Has anyone ever encountered/resolved this situation?
Thank you in advance for your assistance.
-T
![Syndicate content](../../misc/feed.png "Comments for \"All users shown as "offline" until they go Offline and then come back Online\""){kind=small}
More information has surfaced on the problem
The fact that desktop clients work perfectly, but some less known clients have that problem is interesting. What you are experiencing is probably the same that on the mailing list:
Other clients that are reported to have this issue are:
My thoughts/JWGC
Since I also develop a client, I thought I'd mention my mentality for when I first set up my handling of the roster and presence packets. I did make the assumption (and I think reasonable one 'unless told otherwise') that the roster would come first. So I make a note of every member of the roster and label them internally as "unavailable". Then as presence notifications come in I update them accordingly.
Now there's no reason why I couldn't hold onto the presence stanzas until I got the roster.. or done that another way... but it's definitely not something that seems "intuitive" to me. (to get presence before roster) AIM handles this another way by having you get your buddy list (roster effectively) first, and then say "hey, I want you to start sending me presence notifications". (called activating your roster)
Anyway, I can't say whether my client is having this problem or not. I doubt it's highly used. ;D
Not a client problem
Initial research seemed to indicate it was isolated to the “type” of client (fat vs. thin) but additional testing has proven this problem exists using multiple different clients as well as client types. (It happens to everyone that registers)
I replicated this problem with a fresh install and created a bugzilla report with more detail @
-T