security -- how will edit access be restricted? as you know right now
only a committer with an ASF account can change the website (which IMO
is a good thing). how will that ACL translate to the wiki site and
how will it be maintained?
We can restrict edit to geronimo-users, which should only contain
commiters... or if needed make a geronimo-commiters group. Or if we
really want we can create a new plugin to delegate the list of users
and authenticate of them to the main database used by Apache, but
that would take some time to design, implement and convince infra@ to
allow.
So, short-term we limit the entire GMOxSITE space to edit only by
members of geronimo-users (or geronimo-commiters).
performance -- the site seems pretty snappy to me but I have heard
some rumblings about confluence performance. can it handle being
slashdotted?
Well, the site would not be served from Confluence directly. The
AutoExport plugin generates static HTML which is served by Apache
HTTPD... which is hopefully slashdot proof/resistant.
This is static:
http://cwiki.apache.org/GMOxSITE/
This is Confluence:
http://cwiki.apache.org/confluence/display/GMOxSITE/Index
IIRC there is a minor issue where AutoExport renders images and
attachment links back to Confluence which needs to be resolved along
with the other minor issues.... but that is... well... minor ;-)
Also, not sure exactly how http://cwiki.apache.org/GMOxSITE/ would
get sync'd up to http://geronimo.apache.org. Could use a virtual
host and change the CNAME... or probably easier to setup an rsync
that would automatically update SVN to fit into the normal way that
sites work now.
flexibility -- is the wiki flexible enough to handle any html/css that
we can throw at it? for example, the current design was donated by
Epiq a while back and IIUC integrating it into existing website
template system was pretty straightforward. does confluence present
any limitations that would make this type of activity more difficult?
AutoExport (as well as Confluence itself) use Velocity to render...
which is what the current site uses (via Ankia). Take a peek at the
GMOxSITE.vsl velocity template I attached in the initial email which
shows how any HTML can be used for the main skin.
So... its basically the same. With the exception that AutoExport is
using Velocity configured from inside of Confluence and has full
access to the Confluence context variables as well as the plugin
framework which allows other context variables to be added.
One of the main advantages of using Confluence is not not have to
worry about HTML to make great looking pages. So in most cases we
don't want actually content pages to use HTML, though in some cases
we need to, and it is easy to make a user macro for that. In fact I
had to do this for the "News Archive" link...
maintenance -- how much Confluence expertise will it require to
maintain the site, especially if we start using custom plugins, etc?
Custom plugins will add a certain level of additional knowledge...
enough to well... know how to write custom plugins ;-)
But I don't see that we will be doing very much of that... at least
not right now. The only custom plugin work that needs to be done is
to get some fixes into the AutoExport plugin (unless they are already
fixed).
how hard would it be to migrate the site contents to a different Wiki
system or to revert back to a "standard" website if that became
necessary?
Well... that all depends on what "standard" means. If standard means
raw html, then... well no effort, since the site exports to HTML...
only a small change to the template to remove the Confluence page
actions, then regenerate the site and done.
If standard means back to Ankia, then a bit of work to whip up a
template to generate the proper xdocs xml files, then run that once
to generate new files from Confluence and then a tad bit of tidying
up to get it all working from Ankia again. Not trivial... but not
too difficult either.
As for different wiki... well... I'd rather not go there. But if we
did need to then it would be very similar to the above, with a custom
velocity template, this one would not render the pages, but just
include the raw wiki. Then some sort of wiki syntax converter would
be needed to translate to the target wiki's language.
Again I really like the work you've done and think it shows a lot
of promise.
Thanks,
--jason
