[Standards-JIG] Re: Council decision on "Simplified MUC" proposal

Nolan Eakins sneakin at semanticgap.com
Sun Mar 13 20:57:48 UTC 2005

Hash: SHA1

Peter Saint-Andre wrote:
| On Thu, Mar 03, 2005 at 11:20:55AM -0800, JD Conley wrote:
|>For example, it is very useful to get and set multiple items in the
|>#owner namespace with one request.  Our implementation does this today
|>in its management console.  If a namespace was added to the disco
|>features of the component to signal that the MUC+ features were
|>supported I don't see the harm in using existing MUC namespaces where
|>appropriate and where there would be no impact to existing
| In my opinion as JEP author and based on my experience as a service-wide
| admin on all of the jabber.org and xmpp.org MUC services, owner editing
| of an existing room configuration, including adding or removing room
| admins and owners, is a relatively rare occurrence. Modifiying the MUC
| protocol to optimize for infrequently-used features is unnecessary, I
| think. Thus I would disagree that getting and setting multiple items in
| the #owner namespace with one request is truly useful.

The reason I eliminated the #owner namespace for changing an occupant's
affiliation to admin or owner was because it simplifies the
implementation. Both changes uses essentially the same XML as the other
affiliation changes so when you implement them you're best to use the
same code. With the #owner namespace used for around half of the
affiliations you have to check to see what the new affiliation is and
depending on that determine whether to use #admin or #owner.

Granted it's minor, but it simplifies the code used w/o having two
exceptional cases. So using your argument of not optimizing the protocol
for infrequently used features, why must we specialize our code for them?

- - Nolan

PS: I just noticed these messages on this thread. I blame the threaded
display in TBird.
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the Standards mailing list