You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2006/02/05 01:36:21 UTC
Confluence status (was: Why Confluence cannot not be used as a wiki, and how it might be fixed)
Replying primarily for the people on dev@geronimo.a.o. Further
replies should probably just go to infra@. Someone correct me if I'm
wrong.
On Feb 3, 2006, at 7:08 AM, Noel J. Bergman wrote:
> To quote Atlassian: "Confluence will likely die if slashdotted, so
> shouldn't
> be used as a *primary* project website if slashdotting is likely."
> Read
> "slashdotting" as heavy load, and we experience sufficient load on
> the Wiki
> to make caching mandatory.
IMHO, this quote comes out opposite as it was meant.
On Feb 2, 2006, at 4:29 PM, Jeff Turner wrote:
> On Thu, Feb 02, 2006 at 11:56:44AM -0500, Noel J. Bergman wrote:
>> Even Atlassian has recommended against Confluence as a Wiki in our
>> enviroment at this time.
>
> Not quite; Confluence will likely die if slashdotted, so shouldn't be
> used as a *primary* project website if slashdotting is likely.
The distinction made is:
- Confluence as a wiki, Good
- Confluence as a live website, Bad
There are ways to use the *content* create via Confluence in a
website. A number of people have working solutions already. Most
fall into one of or a mix of this:
1. Serving static pages that are generated whenever from content
in Confluence
2. Smart front-end generating and caching pages from Confluence
A few projects do this successfully now. The Directory guys have
nice system they worked up:
- Confluence Page: http://docs.safehaus.org/display/APACHEDS/
Protocol+Providers
- Static page in svn: http://directory.apache.org/subprojects/
providers.html
Of course the Maven guys have a maven/docs based tool that does the
same:
- Confluence Page: http://docs.codehaus.org/display/MAVENUSER/FAQs
- Static page in svn: http://maven.apache.org/auto-faq.html
I think we are in good shape sans the fact that we should have our
own confluence install. There seem to be a few good options for that
too. I'm not quite as crystal clear on the status of those options.
Someone help me out as I will likely get this wrong:
1. Host confluence on a dedicated box provided by Atlassian in
our colo.
2. Refit one of our existing boxes to host confluence.
3. Have Contegix host the confluence sponsored by Atlassian.
4. Something I missed completely.
Hope this helps serve as a good "checkpoint" in the discussion.
Clarifications/corrections/comments welcome.
-David
Re: Confluence status
Posted by Jeff Turner <je...@apache.org>.
On Sun, Feb 05, 2006 at 04:50:13AM -0500, Joe Schaefer wrote:
...
> IIRC the technical requirements come from experience with the existing
> moin-moin wiki, so that's probably the context best suited for Noel's
> remarks.
Yes, and I think it's a fair approach to take.
Here's how I see things going forward..
1) Towards Confluence as a direct MoinMoin alternative
Infrastructure@ want some decent benchmarks demonstrating that Confluence
can survive sustained heavy load (ala MoinMoin) and/or spikes (slashdot).
Noel rightly says caching is essential. Briefly experimenting with 'ab -c
100 -n 1000' suggests that Confluence's internal caching may be enough.
I'll ask the Confluence team if they can produce some benchmarks.
2) Confluence as doc staging/development environment
There are various ways to suck content from Confluence to a live site:
- Maven has Doxia in development.
- Codehaus have a Perl script (Confluenza) which sucks down content via
XML-RPC to build their website.
- Pier is working on a Confluence plugin that saves static HTML.
- Anyone can rig up a script using Confluence's XML-RPC/SOAP API.
Confluence does not have to be running on ASF hardware for its use as a
doc staging environment. Some projects might use the Codehaus Confluence,
some use http://opensource2.atlassian.com/confluence/oss/. It would be
nice if the ASF had an internal Confluence installation for doc staging,
and that's what I proposed Atlassian would sponsor a box (partly) for.
--Jeff
> --
> Joe Schaefer
Re: Confluence status
Posted by Joe Schaefer <jo...@mail.sunstarsys.com>.
[i'm not on dev@geronimo, so the moderator there will have to
push this thru]
David Blevins <da...@visi.com> writes:
> Replying primarily for the people on dev@geronimo.a.o. Further
> replies should probably just go to infra@. Someone correct me if I'm
> wrong.
>
> On Feb 3, 2006, at 7:08 AM, Noel J. Bergman wrote:
>> To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't
>> be used as a *primary* project website if slashdotting is likely." Read
>> "slashdotting" as heavy load, and we experience sufficient load on the Wiki
>> to make caching mandatory.
>
> IMHO, this quote comes out opposite as it was meant.
>
> On Feb 2, 2006, at 4:29 PM, Jeff Turner wrote:
>> On Thu, Feb 02, 2006 at 11:56:44AM -0500, Noel J. Bergman wrote:
>>> Even Atlassian has recommended against Confluence as a Wiki in our
>>> enviroment at this time.
>>
>> Not quite; Confluence will likely die if slashdotted, so shouldn't be
>> used as a *primary* project website if slashdotting is likely.
>
> The distinction made is:
>
> - Confluence as a wiki, Good
> - Confluence as a live website, Bad
IIRC the technical requirements come from experience with the existing
moin-moin wiki, so that's probably the context best suited for Noel's
remarks.
>
> There are ways to use the *content* create via Confluence in a website. A
> number of people have working solutions already. Most fall into one of or a
> mix of this:
>
> 1. Serving static pages that are generated whenever from content in
> Confluence
> 2. Smart front-end generating and caching pages from Confluence
My concern is that people will be far less creative in how they manage
their content if there's an asf-endorsed wiki they can just point users
at. IOW, are people doing similarly creative things with the moin-moin
wiki, or do they normally just refer folks directly to the content on the
"apache wiki"?
> I think we are in good shape sans the fact that we should have our own
> confluence install.
We'd be in better shape if we could just get confluence to perform as
well as moin-moin, so policing people's usage would be less of a concern.
When it comes to options, the issue of failure recovery is important.
What happens if the box dies; does the content die with it? What will
happen to the projects dependent on an asf confluence if the technical
support for it (which is a perpetual committment) diminishes over time?
--
Joe Schaefer