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
encodeURL().
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 ;-)
/Janne
