incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: WikiSpaces follow-up
Date Tue, 05 Feb 2008 16:50:47 GMT
> Ok. That actually makes a LOT of sense. The rule would be: "We  
> don't care how many webapps you have, but all of your space names  
> should be globally unique if you expect to apply a common policy to  
> it." It could cause some confusion, but these could be worked- 
> around, and there won't be confusion in the default cases.

Yes, exactly.

> PS. At the risk of opening a can of worms, we ought to externalize  
> URL re-writing in JSPWiki 3 via Response.encodeURL(). Experimenting  
> with that now... Heh.

You can't assume that HttpResponse is always available, e.g. when  
embedding.  In fact I think that using that goes completely contrary  
to the idea of separating rendering from the core.

However, it might make sense to provide URL rewriting method in the  
WikiContext, which would, if the response were available, would call  

But, considering that JSPWiki is very link-intensive anyway, I would  
much rather get the URLs right the first time, instead of rewriting  
them on the fly all the time.

>> I agree, I think groups and account management should be per- 
>> WikiEngine and per-property -file, common to all Spaces which are  
>> running under this Engine.
> Not sure what you mean here. What would define the "namespace" for  
> each WikiEngine or property file? How would you distinguish them?  
> And how would we explain that this is somehow different from a  
> "space"? (I am trying to visualize the policy file: explaining that  
> the *:* for PagePermission means <space>:<page>, but the * in  
> GroupPermission means <wikiengine-or-propertyfile>.)

Sorry, I was being a bit vague.  No, what I meant that a single  
WikiEngine should have a single UserDatabase and a single  
GroupDatabase.  However, in the policy file the GroupPermission "*"  
would mean the space.

The regular user should not really have to know the di

>> Indefinite nesting.
> Dammit. I was hoping to escape without much work. :)

Think about permission inheritance ;-)


View raw message