On this issue of caching, I don't know if it has been raised but on Codehaus we use a confluence wrapper called Confluenza (http://despots.codehaus.org/Confluenza) that provides both a nicer web site for projects and it does caching of confluence pages.
Here's an example of confluenza in action: http://cargo.codehaus.org (notice the Edit button in the lower-right corner. Clicking on it leads to the confluence edit view). Thanks -Vincent > -----Original Message----- > From: Hernan Cunico [mailto:[EMAIL PROTECTED] > Sent: vendredi 10 février 2006 17:21 > To: [email protected] > Subject: Re: Why Confluence cannot not be used as a wiki, and how it might > be fixed > > 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+Ca > ch > >>> > >>> 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 > >>> > >>> > >>> > >> > >> > >
