geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
Date Thu, 09 Feb 2006 23:28:55 GMT
Hiram Chirino wrote:
> 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.

Can exporting to a static site be done today, or do tools need to be 

Even if we do this to overcome the Confluence performance concerns won't 
that mean we still need to retain a Wiki for users to use (hopefully 
without duplicated content) and therefore still have Moin Moin running 
for Geronimo (until Confluence performance concerns are addressed)?



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