Dnia 2012-11-08, czw o godzinie 13:35 +0100, Sylvain Guglielmi pisze: > - creating my own module "mod_preventrosterchanges". This module would > only "handle" roster changes by dropping them, and pass everything else. > It would be added to the "in-session" chain, just before "mod roster".
This is the preferred solution, as the job of mod_roster is to handle user roster in persistent way. Adding an option to disable its basic function smells. This is exactly what chains were created for. You can write your own special case module and use it. You may create a feature request [1] if you do not want to write this module yourself. > only problem would be that clients will not get a Roster Push > (http://tools.ietf.org/html/rfc6121#section-2.1.6) when the roster is > updated using the previous system. This could probably be fixed with > another component sending Roster Push stanzas at sess_start when > updating roster from the existing database. jabberd2 does not support tinkering with storage data outside of the server. In current architecture, storage is not authoritative data source, and serves only as a persistence layer to data structures in server processes. If you need to, you may write a component that impersonates as a user and changes its roster using standard XMPP packets. Alternatively you may extend command port [2] with support for editing user roster. [1] https://github.com/Jabberd2/jabberd2/issues/new [2] https://github.com/Jabberd2/jabberd2/blob/master/c2s/pbx_commands.c -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
