On Fri, Jan 22, 2010 at 5:31 PM, Dave Cridland <[email protected]> wrote:
> 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. Just looking ahead - we'll be hitting that over the next few weeks, i.e. section 10 is planned for week 5 and section 15 in week 6. I know we'll be getting more like this with something as large as muc taking that long. For example I'm double checking something of my own over the weekend which is in section 6 but probably needs talking about when we reach 18 (Schemas) As for muc#roomconfig_publicroom being a tristate i'm not sure. I can see it being a boolean due to "public" 1 and "hidden" 0, but what affect would having other values have with existing clients? Perhaps this one we should think through whilst we get through the next set of sections. In Peter's plan its one week for each of the next four sections (7-10). Peter -- Peter Mount e: [email protected] w: http://retep.org xmpp:[email protected] <xmpp%[email protected]> MSN: [email protected]
