geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
Date Fri, 03 Feb 2006 16:09:24 GMT

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.


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:
> +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

View raw message