On Thu, Apr 28, 2011 at 3:14 PM, Peter Saint-Andre <[email protected]> wrote: > On 4/28/11 9:52 AM, Dave Cridland wrote: >> On Thu Apr 28 14:49:35 2011, Evgeniy Khramtsov wrote: >>> 28.04.2011 23:19, Matthew Wild wrote: >>>> On 28 April 2011 14:13, Yann Leboulanger<[email protected]> wrote: >>>> >>>>> >>>>> Unfortunatly the goal of this XEP is not met: latest ejabberd and >>>>> prosody >>>>> don't implement that XEP. I've not checked other servers. >>>>> >>>>> >>>> http://code.google.com/p/prosody-modules/wiki/mod_blocking >>>> >>>> It's waiting for client support, testing, and feedback before we can >>>> include it in a release. >>>> >>>> Regards, >>>> Matthew >>>> >>>> >>> >>> There is a patch available for ejabberd as well: >>> https://support.process-one.net/browse/EJAB-695 >> >> And just to join the vapourware announcements, the next release of >> M-Link will be shipping with XEP-0191 as well. We've also implemented a >> XEP-0050 suite of commands to control it, in order to side-step the >> client/server/chicken/egg problem to some degree. > > In fact it might have been better to just do ad-hoc commands, but the > feedback at the time was that people wanted a simple, one-off control > for "block this user". At least that's how I interpreted the feedback...
I think that's Right. The ad-hocs are a temporary work-around because clients don't support 191 because servers don't support 191 because clients don't support 191 because servers... It's possible to give a generally nicer user experience around known commands than it in ad-hocs. (I neatly sidestep the issue of known ad-hoc nodes and semantics). /K
