[JDEV] Auto roster population/lock some groups

[Iain shigeoka]

On Thursday, Sep 11, 2003, at 09:07 US/Pacific, Alon Weinstein wrote:

> I can't answer your question, as I am not fluent in XMPP-ish myself, 
> however there is one point you should note -- though technically you 
> could get away with putting logic only in the clients to block changes 
> (using XMPP's standard way to enhance the protocol; you can find info 
> about it in lots of places), you shouldn't -- the server must handle 
> this logic. Why? because if the server will only be a data-store for 
> this kind of data people could login using some other XMPP client and 
> avoid the restrictions, and that is probably a security problem, or at 
> least a wrong implementation of specifications.

I tend to agree. Using the client to enforce the business logic is 
probably not what you want to do. Imagine if the powers that be decide 
they want two sets of locked groups in the future, one that can not be 
changed by anyone, and one that can only be changed by certain users. 
And they also decide to start using more client types on more devices 
(web, PDAs, desktop, etc - you'd be surprised how fast that usually 
occurs when they learn they're using a standard protocol supported on 
every platform known to man). :)

Since there will be only one server it's much easier to manage from the 
server than from the client side. In addition, ultimately, rosters are 
stored on the server so it's where you can exert the most control. How 
to do that in jabberd I leave to the experts. I imagine it's going to 
be some custom coding around the roster code. In addition, you'll need 
to decide if you're going to work on the jabberd 1.4x codebase or the 
jabberd 2 code base (the former is stable but will be entering 'end of 
life' at some point, the latter is in beta but is the future of 
jabberd).

-iain
Jive Software http://www.jivesoftware.com
Jive Messenger XMPP Server