Replies inline: On Sat, May 16, 2009 at 11:18 AM, Greg Kable <[email protected]> wrote: > I'm assuming that the idea is for 3.0 to implement separate wiki spaces so > that a single instance of JSPWiki can host multiple, independent wikis > instead of requiring separate deployments. If that's not the case, can > somebody please explain spaces or point me to where I can read up on them.
Yes, that's about right. > If my assumption is correct, then I think we need to add getSpace() to > either or both WikiPage and WikiContext (my vote) so that plugins can make > sure that they limit their activities to the current space. If not, it's > going to be very hard to prevent information from leaking between spaces via > plugins. I'd support adding this to WikiPage, although it can already be obtained via WikiPage.getPath().getSpace(). I don't think it's needs to be added to WikiContext. For what it's worth, the idiom we've adopted, de facto, is that if a space isn't supplied, the a parsed page name is interpreted as belonging to the ContentManager.DEFAULT_SPACE space. We haven't been entirely consistent on how page names are rendered, though. Some plugins render the name with the space name always included... but some don't. This is probably worth rationalizing across the code base. An area of glaring weakness, at the moment, is adding path-awareness to the PagePermission class so that permissions that apply to hierarchical page names are correctly interpreted. That's probably the key missing item in terms of getting spaces to actually work. Most of the other support is already there, although we should change much of the code that relies on WikiPage.getName() to use WikiPage.getPath() instead. This is also worth rationalizing. :) > I also think it's likely that we'll need to have space specific versions of > WikiEngine.getConfigParameter() and WikiEngine.getAllConfigParameters() as > it's very likely that people will want to have different parameters for > different spaces. I'm not so sure about this, but it might make sense. There's already a system set up for "cascading" properties, which perhaps this could be aligned with. One of the areas where the configuration would not make sense to vary between spaces is security: in particular, user authentication, roles and groups. I don't want to start having to disambiguate names across authentication realms, or across group collections. Essentially, we've had a one-webapp, one-realm rule and I expect that to continue. Other than that, I'd defer to Janne and the rest of the dev team on this. > Is this reasonable or not? > > Thanks, > Greg >
