geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Geronimo site POC using Confluence & Autoexport
Date Tue, 25 Jul 2006 18:48:08 GMT
> 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  

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:

This is Confluence:

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 would  
get sync'd up to  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  

> 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.



View raw message