On Fri Jan 22 17:22:59 2010, Peter Saint-Andre wrote:
That's nice if you want to check the member list, security
clearance, or
other information before returning disco#items results, but it is
out of
scope for XEP-0045.
It's the security clearance, mostly in our case, but as a general
thing, it seems vaguely sensible.
> The muc#roomconfig_publicroom option possibly always lists,
possibly the
> inverse never lists, and possibly controls listing absolutely.
See above.
> But if it's the latter, then how does one achieve option 3 for a
set of
> rooms?
If you want to do Option #3 in your implementation, that's great,
but it
is a special product feature that you can tout in comparison to your
competitors. :)
Right, but if we also want to support muc#roomconfig_publicroom, and
"blind" clients which don't actually parse the form (and there are a
few), then we're a bit stuck.
The problem is that muc#roomconfig_publicroom is a boolean, whereas
it needs to be a tristate.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
