geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <hcun...@gmail.com>
Subject Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
Date Fri, 10 Feb 2006 16:20:50 GMT
Hi All,
is there a way to know how many updates to the MoinMoin wiki we have a day?

Most of the content is static or don't change very often. How many people are adding content
to the 
wiki on a daily basis?

Is there a way to list all the registered users and their recent activity?

If most of the content is static then it should be easily cacheable. It would be great to
know what 
is the traffic we currently have on the MoinMoin wiki (for Geronimo and for the whole ASF)

Cheers!
Hernan

John Sisson wrote:
> 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 
> written?
> 
> 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,
> 
> John
> 
>>
>> 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
>>>
>>>
>>>
>>
>>
> 

Mime
View raw message