Steven, After doing this, does the Jabber server continue to send presence messages to indicate when they logoff, change status, etc.? Or, do you need to poll for these changes? So, let me see if I understand this, when your client connects, you have it send one of these promiscuous messages to let all the other connected users know you're available? That then gets forwarded to all the currently connected clients. Does the newly connected client also get notified of all the other users that were already logged in as well?
This sounds pretty good, but I think this solution would create some other problems for me. First, I doubt these promiscuous presence messages contain additional information such as nickname? Do you just display the jid or jid handle on the clients? The handles in our database are not unique. Therefore, I use our unique numeric user_id for the jid, but always set the nickname on roster entries so that something user friendly can be displayed. More importantly, the roster query that returns roster items including logged in users currently filters the logged in users. For example, for legal reasons, I only show logged in users that match the requesting jid's age group (< 18 or > 18). Since this is all handled in a stored procedure, we could easily add additional filtering in the future as well (similar interests, etc.). Using your approach, I would also be concerned that I could start getting back too many logged in users? If the Jabber IM feature becomes popular on our website, we might have hundreds of simultaneously connected users. I would definitely want to filter that down to a more reasonable number. -- Ryan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Brown Sent: Friday, September 26, 2003 8:39 PM To: [EMAIL PROTECTED] Subject: RE: [JDEV] Online Roster Group > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ryan L. Hart > Sent: Friday, September 26, 2003 2:35 PM > To: [EMAIL PROTECTED] > Subject: [JDEV] Online Roster Group > > > I'm using xdb_sql to process roster queries. I would like to > return a small group of online users in a separate group so > that users have somebody to talk to. This much I'm doing, I > return the logged in users with subscription = 'to' in group > = 'Logged On'. These online users show up on the client side > as expected, but they are all marked as Offline. This is > obviously because there was never a corresponding 'from' > subscription from the logged in users to this newly logged on > user, so the Jabber server never sends the presence > information. > > Is there a good solution to this problem? I'm assuming I > could have my clients repeatedly request presence for all the > users in the 'Logged In' group, but that seems ugly. What > about picking up newly logged in users every once in awhile? > Would that be just having the client send another roster get > request? That's less important though. I really just want > the 'Logged In' group to show accurate presence information > like all my other groups. Btw, I just got done (hopefully) hacking Jabber for our use to do similar: have a set of users on the same server always known to the client. I call it promiscuous mode. A client wanting to have their presence known to all connected users on the same server sends <presence type="promiscuous"> and I hacked mod_presence.c to properly handle all the cases involved with broadcasting presence. The non-promiscuous initial available path through mod_presence.c has an additional presence probe other than the roster s10ns that probes all connected users on the same server. The probe response logic understands promiscuous, so all promiscuous users reply if it's the same server. Like invisible, promiscuous presence never makes it to the client looking like that. It's modified into available presence with a <promiscuous/> tag under it so that clients that understand promiscuous mode can act accordingly (like making them appear in the roster or whatever). I decided not to modify the roster at the server, as it gives my client more flexibility as to what it chooses to represent them as, but it could be added pretty easily. If folks are interested, I could try extracting that patch from the rest of my changes and post it. The protocol itself might make a neat JEP, as I'm sure many folks use Jabber servers for supporting user communities, and promiscuous mode is rather ideal for that. _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
