Hi,
I was just looking into these issues in regard to the activemq and
servicemix sites. I really do like confluence a ton and would
eventually like to see be part of the ASF infrastructure.
What I would like is to just export the confluence content to a
static site. This would allow us to also enhance/style/aggregate the
content during the export so that nice looking project websites are
the results.
Regards,
Hiram
On Feb 3, 2006, at 10:40 AM, Rodent of Unusual Size wrote:
Forwarding to the dev@ list with permission. This
is where it belongs.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
See:
http://confluence.atlassian.com/display/DOC/Running+Confluence
+Behind+a+Cach
ing+Proxy+Server
The comment:
"The main problem with the reverse-proxy solution is that every
Confluence page is built dynamically for whichever user is
currently accessing it."
is a typical indicator of a common problem in many dynamic content
systems,
which all too often neglect the fact that 99.999+% of all traffic
is going
to be relatively static and anonymous. Dynamic does not mean
ephemeral, and
that distinction is missed all too often.
The facts are that most Wiki access is anonymous, and Wiki content
is almost
entirely static and should be cachable. Confluence intentionally
breaks
caches, and that behavior needs to be fixed. There are a number of
possible
solutions.
One way, and just a simple one, since there are others, would be for
anonymous and authenticated access could have different URLs, e.g.,
mydomain.tld/confluence/anon/ for the public, and
mydomain.tld/confluence/auth/ for authenticated users. That would
permit
the vast majority of accesses to be cached. "WAIT", you say, "What
about
when someone edits the page under the /auth/ path? Won't that cause a
problem for viewers in the /anon/ path?" Not if the URLs are properly
designed, and the system is supporting Conditional Get. The /anon/
path
should be handling Conditional Get based upon the timestamp of the
page
resource. So most GET requests will simply return 304, unless the
page has
been changed, in which case the updated resource can be returned
and cached.
So these are technical issues (Joshua Slive outlined other,
related, ones),
and the ball has been in Atlassian's court to provide some resolution.
--- Noel
