[JDEV] Online Roster Group

[Steven Brown]

> -----Original Message-----
> From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org] On 
> Behalf Of Ryan Hart
> Sent: Saturday, September 27, 2003 5:45 AM
> To: jdev at jabber.org
> Subject: RE: [JDEV] Online Roster Group

> After doing this, does the Jabber server continue to send 
> presence messages
> to indicate when they logoff, change status, etc.?

Yes, it works like presence for someone on your roster list. 

> 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?

Every connected user on the same host is notified of presence from every
promiscuous user on the same host.  Barring the possibility of bugs in
my implementation, all the edge cases work as would be expected - just
like for buddies.

> 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?

Only the roster contains nickname.  Users who are not your buddy have no
nickname, as you must assign them one.  

> Do you just display 
> the jid or jid
> handle on the clients?

Currently, my client (will) display promiscuous users with the username
component of their jid.  Since they are all on the same server, there is
no need to display anything more.

 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.

In your case, you would want the server to modify the roster, at least
what appears to be the roster (you don't actually have to modify the
roster to place a roster entry on the client).  This, and the filtering
you mention, could be done in the server when a promiscuous presence is
about to be sent to a client.

I will look into extracting a version of my promiscuous modification on
Monday.