geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: Why Confluence cannot not be used as a wiki, and how it might be fixed
Date Sat, 11 Feb 2006 16:42:11 GMT
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:hcunico@gmail.com]
> Sent: vendredi 10 février 2006 17:21
> To: dev@geronimo.apache.org
> 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
> >>>
> >>>
> >>>
> >>
> >>
> >


Mime
View raw message