You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2002/08/06 20:24:36 UTC
Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Sylvain Wallez wrote:
> Bertrand Delacretaz wrote:
>
> >On Tuesday 06 August 2002 08:58, Steven Noels wrote:
> >
> >
> >>. . .
> >>phpWiki looks nice, but running PHP
> >>as an Apache2 module doesn't work for me.
> >></sidenote>
> >>. . .
> >>
> >>
> >
> >I don't know about an RCS backend but these might be interesting:
> >
> >http://chiki.emaho.org/
> >based on Struts
> >
> >http://moin.sourceforge.net/
> >Phyton-based but provides an XML view of the content
> >
> >
>
> Have you looked at JSPWiki at http://www.ecyrd.com/JSPWiki ? It's very
> lightweight, and has two features I wanted : versioning and support for
> tables. It has a pluggable versioned filesystem implementation which
> come in two flavors : RCS and flat file.
I had it already installed at http://outerthought.net/wiki/, but I
wasn't able to get RCS working immediately - did you? I will try to
tweak it this evening. Chiki offers versioning information as well.
> We've been using it internally for a few weeks (I tweaked a bit the
> presentation) and I must say a wiki really changes the way of building
> and sharing information in a group. Some people (including myself) also
> use this wiki as a personal scratchbook because of its ease of use, and
> the fact that it is visible to others turns a personal itch into some
> collective thinking.
>
> Writing on a wiki is also different from writing on a mailing list : on
> a ML, you can throw an idea in a few lines and see if you get some
> feedback. On a wiki, your thoughts have to be more cleanly structured in
> order to be presented. This also helps maturing ideas.
>
> As said in Nicola Ken's signature, "verba volant, scripta manent"
> (discussions get forgotten, only _writings_ remain). And the experience
> of lost RTs shows that a mailing list, even with its archive, is mainly
> discussions.
A wiki for RT's would be really, really great. Do I proceed with my setup?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Le...@ingenta.com.
Diana:
>>Sorry if this is an stupid question, but can Wikis check
>>links (included in submitted content)?
No. But there are automated tools for checking link integrity, I believe
there are some open source options if this is a burden.
Steven:
> I've just put up a copy of JSPWiki on my server, and Leigh Dodds of
> Eclectic and xml.com fame is filling it already with his contributions
> (lots).
Yep I've just completed a dump of all my research notes. Hope they're useful.
> <quote src="leigh" medium="private mail">
> I think just putting up a chunk of content will decide where the
> Wiki lives.
> </quote>
I should qualify this and say that I wouldn't presume to pre-empt any 'official'
process, but I also didn't want to see several Wikis spring up with overlapping
content. So I just picked one that used the same platform as my research notes
instance, and pasted the docs in.
Besides, Wiki sites work better once they've been seeded with content.
> Content is king, and we should applaud Leigh for giving us such a
> tremendous headstart. Feeling much obliged - we will take of this.
No probs. I haven't had time to contribute code, so this is my way of helping out.
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Diana Shannon wrote:
>
>
> I've just put up a copy of JSPWiki on my server, and Leigh Dodds of
> Eclectic and xml.com fame is filling it already with his contributions
> (lots).
>
>> Syvain, how's http://www.anyware-tech.com/wikiland/ faring?
>
Once again about wikiland : it's an attempt to build a Cocoon-based
wiki, and feeding it with Cocoon-related content was meant to attract
Cocoon-related people. And its rather asleep now...
> <quote src="leigh" medium="private mail">
> I think just putting up a chunk of content will decide where the
> Wiki lives.
> </quote>
>
> Content is king, and we should applaud Leigh for giving us such a
> tremendous headstart. Feeling much obliged - we will take of this.
>
> If you feel like wiki'ing, have a look at http://outerthought.net/wiki/
I completely agree with the above and what others said in this thread :
we should not delay the use of a wiki because we don't have a
Cocoon-based wiki. And even more because a wiki *is* its content more
than its infrastructure.
Let's start _today_ with something that works _today_ and if one day a
cool Cocoon-based wiki is available (be it wikiland or something else),
then we may consider migrating the content.
So let's go on with Steven's JSPWiki installation and see how it lives.
It's better to do something with tools that may not be the ultimate ones
than building these ultimate tools and delay forever what we wanted to
do with them.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
>
> On Tuesday, August 6, 2002, at 02:24 PM, Steven Noels wrote:
>
>>>
>>> Writing on a wiki is also different from writing on a mailing list : on
>>> a ML, you can throw an idea in a few lines and see if you get some
>>> feedback.
I didn't wrote that, check your indentation ;-)
> True, but on cocoon-users, there are some great threads which yield good
> doc material. The problem now is a lack of doc committers and patches
> from volunteers. Perhaps we should be encouraging users to post their
> summaries in a wiki-like grammar on cocoon-users. I guess the quality of
> doc-oriented wikis will depend in part if uber-knowledgeable people,
> like Vadim, Christian, and others, spend time monitoring/editing
> doc-wikis like they do currently on cocoon-users. Since Vadim started
> this wiki topic, sounds like he'll be visiting it??? Seems to me we'd
> need a QA stage before commits to cvs.
Agree. A Wiki might be such a QA tool, I believe. And since the back-end
of JSPWiki (read below) stores its content as plain text files, and we
have Chaperon at our disposition, XML-izing the result afterwards
wouldn't be too much of a problem.
>>> On a wiki, your thoughts have to be more cleanly structured in
>>> order to be presented. This also helps maturing ideas.
>>>
> Yes, but in some ways, **until** we can transform Wiki content into a
> structure based on document.dtd, etc., isn't this a step backwards for
> some of the more complex-structured docs? In other words, it seems it
> could significantly increase the burden on committers making periodic
> updates to cvs, etc. I also worry a bit about managing links introduced
> by Wiki docs. Link troubleshooting already consumes a huge chunk of my
> volunteer time. Sorry if this is an stupid question, but can Wikis check
> links (included in submitted content)?
Must be investigated, but I consider *any* progress to be important
enough to live with the results (and pitfalls) they might cause. Wiki
links are only 'established' once the target page exists. We will have
too see how this transposes into the XML world.
>> A wiki for RT's would be really, really great.
>
> I think we should seriously consider doing individual FAQs/Topics this
> way, i.e., one page for each FAQ/Topic.
>
>> Do I proceed with my setup?
>
> Would this now become a Forrest sub-project? Will doc committers have
> access to the resources/files they need?
I've just put up a copy of JSPWiki on my server, and Leigh Dodds of
Eclectic and xml.com fame is filling it already with his contributions
(lots).
> Syvain, how's http://www.anyware-tech.com/wikiland/ faring?
<quote src="leigh" medium="private mail">
I think just putting up a chunk of content will decide where the
Wiki lives.
</quote>
Content is king, and we should applaud Leigh for giving us such a
tremendous headstart. Feeling much obliged - we will take of this.
If you feel like wiki'ing, have a look at http://outerthought.net/wiki/
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by MJ Ray <ma...@cloaked.freeserve.co.uk>.
Steven Noels <st...@outerthought.org> wrote:
> [...] it is currently not up-to-speed with other Wiki implementations
[...]
Please be cautious. The original wiki at http://c2.com/cgi/wiki?FrontPage
should be the benchmark, not any of the BellsWhistlesAndStuffTheWikiWay
implementations. I don't know whether the others you mention are from that
family, but wikis are intentionally lightweight.
--
MJR|
---'
|-----[ Luminas internet applications http://www.luminas.co.uk/ ]-----|
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Steven Noels wrote:
>
> Thanks Ulrich. We all understand your point. It's just that we have
> other priorities right now. Or better: this is a volunteer effort, you
> can't force people to go into your direction.
Of course not, but I am not aware of having tried.
> If you want to influence
> the course of an open source project, the only way to do so is by
> contributing (and I know you did with Avalon).
Isn't that what I'm doing right now? Contributing ideas. Whether they
are useful to others is another question - but surely no-one gets dumber
by reading my comments? :)
As for contributing code, I was not able to explain to my employer the
ROI of migrating all our Cocoon1-based apps to Cocoon2. So all I can do
now is comment occasionally. The ROI of Avalon/Phoenix was easier to
explain and they had zero docs at the time.
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Ulrich Mayring wrote:
> Andrew C. Oliver wrote:
>
>> <snip/>
>> Every documentation discussion has broken down into a "lets develop
>> undocumented tool X to serve the documentation!" and
>> faded.
>
>
> My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
> MS-Word format, because PDF creation is too unwieldy? No, they made PDF
> creation easy instead.
>
> Ulrich
>
Thanks Ulrich. We all understand your point. It's just that we have
other priorities right now. Or better: this is a volunteer effort, you
can't force people to go into your direction. If you want to influence
the course of an open source project, the only way to do so is by
contributing (and I know you did with Avalon). For documentation,
content is equally important as infrastructure. Some of us are focussing
on content. If you come up (preferably together with Olivier Rossel)
with a Wiki solution that runs on top of Cocoon and offers a
footprint/feature set comparable with JSPWiki (which is a pretty
lightweight WikiEngine anyhow), I'm quite sure it will be well received
by this community. I'd be happy to host it, too.
I should be leaving on holidays soon. If you are looking for a group of
like-minded documentation bone-headed people to discuss documentation
infrastructure tools, please go and visit http://xml.apache.org/forrest/.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Andrew C. Oliver wrote:
> Ulrich Mayring wrote:
>
>> My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
>> MS-Word format, because PDF creation is too unwieldy? No, they made
>> PDF creation easy instead.
>
> My point: So develop the tool. We'll switch to it once you develop the
> tool.
I'm not a Cocoon developer anymore :(
> The rest of us shouldn't STOP documenting until an adequate
> Cocoon Wiki exists.
Agreed. So, everyone is busy writing docs now? :)
> Did Microsoft close Hotmail until it could convert
> it to NT? No. Hotmail ran for a good year or two on UNIX servers after
> being bought by MS.
Initially MS wasn't aware of the bad publicity this could create, so it
was deemed a non-problem. After the bad publicity arose, it became their
first priority to switch over to NT. That took as long as it took, but
it was first priority.
The developers of BeOS were compelled to develop under BeOS. The CEO
said that the product would only become good, if the developers actually
had to work with it. They were given intentionally slow machines, too :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ulrich Mayring wrote:
> Andrew C. Oliver wrote:
>
>> <snip/>
>> Every documentation discussion has broken down into a "lets develop
>> undocumented tool X to serve the documentation!" and
>> faded.
>
>
> My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
> MS-Word format, because PDF creation is too unwieldy? No, they made
> PDF creation easy instead.
My point: So develop the tool. We'll switch to it once you develop the
tool. The rest of us shouldn't STOP documenting until an adequate
Cocoon Wiki exists. Did Microsoft close Hotmail until it could convert
it to NT? No. Hotmail ran for a good year or two on UNIX servers after
being bought by MS. Documentation is MORE critical than hosting the
documentation on a Cocoon-based site. Just like MS signing up more
hotmail users so that they could invade their privacy was MORE important
then running it on NT at first.
-Andy
>
> Ulrich
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Andrew C. Oliver wrote:
> <snip/>
> Every documentation discussion has broken down into a "lets develop
> undocumented tool X to serve the documentation!" and
> faded.
My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
MS-Word format, because PDF creation is too unwieldy? No, they made PDF
creation easy instead.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Priorities [was: Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)]
Posted by Ivelin Ivanov <iv...@apache.org>.
Agreed!
We've started discussing the release plan for 2.1 and we ended up on another
planet again.
Here go my votes in order of priority:
1) Feature freeze for 2.1
2) Announce 2.1 Alpha stage on the main Web Site, so that people that don't
follow the threads are aware of the plan.
3) Improve documentation for 2.1
4) Announce one month voting period for users and developers to decide which
components of Cocoon do not need to be included in the core.
5) Move low voted components back to scratchpad.
6) Announce 2.1 Beta in December-January timeframe
7) Wait until majority of us are comfortable with the quality of the
documentation and the code.
8) Release 2.1 in March-April time frame
As a side task, if someone is willing to work on a build script which allows
modules to be included or excluded from a build, it will be great. While
this is critical for an OS kernel, it is not necessarily a show stopper for
a J2EE server. Weblogic comes as a 100mb install, while we don't use more
than 10mb. Same with WebSphere and other J2EE servers. Cocoon is not exactly
a J2EE container, but it is as sophisticated in many ways.
Disk space is not such a big issue. As long as it is a stable build, size is
not that important on the server side.
Also, when are we merging Forrest with Cocoon's web site?
Regards,
Ivelin
----- Original Message -----
From: "Andrew C. Oliver" <ac...@apache.org>
To: <co...@xml.apache.org>
Sent: Wednesday, August 07, 2002 6:11 AM
Subject: Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and
modularize it . . .)
> <snip/>
>
> >
> > The marketing-savvy people will also fail to adopt Cocoon if there
> > isn't any good documentation with it. So let's stop discussing the
> > 'how', and focus on the 'what'.
> >
> > </Steven>
>
> BIG TIME! +10000000000000000000000000000
>
> Every documentation discussion has broken down into a "lets develop
> undocumented tool X to serve the documentation!" and
> faded.
>
> -Andy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
<snip/>
>
> The marketing-savvy people will also fail to adopt Cocoon if there
> isn't any good documentation with it. So let's stop discussing the
> 'how', and focus on the 'what'.
>
> </Steven>
BIG TIME! +10000000000000000000000000000
Every documentation discussion has broken down into a "lets develop
undocumented tool X to serve the documentation!" and
faded.
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Ulrich Mayring wrote:
> I'm sure there are good reasons, but from a marketing point of view this
> is a show-stopper. It gives the impression that Cocoon is so hard to use
> that even the devs themselves prefer lighter tools.
Showstopper is a strong word - use it cautiously IMO.
There's two problems here:
* building the app
* hosting the app
Building the app shouldn't be a problem, hence wikiLand
(http://www.lolive.net/). From what I can see however, this is a one-man
show and it is currently not up-to-speed with other Wiki implementations
(not meaning to criticize the work of Olivier, just stating the facts
as-is). JSPWiki has a small but thriving community and is more
feature-advanced then wikiLand.
Now about hosting a Cocoon Wiki:
I and some others have been spending literally *hours* discussing the
use of Java webapps on ASF-infrastructure for Forrest purposes on
infrastructure@apache.org. Given the current state of Java VM's on
FreeBSD and other issues, this is not an option on daedalus nor on
icarus. Pier Fumagalli has offered us access to nagoya, but given my
lack of experience with the Solaris platform, and the fact that Pier
already is doing many thing for ASF, I went for my own server instead
for various Cocoon/Forrest/documentation related experimentations.
I don't have the knowledge nor the time to host a true Sourceforge-like
Cocoon development environment, where people can work on a shared
Cocoon-based webapp, recycle Tomcat as needed, configure cocoon.xconf,
etc, all in a secure and easy-to-maintain way. So I opted for the
sysadmin-fascist approach: I am root on my own server, so I can install
what I want and hopefully provide some useful tools to the community.
I use what is in my reach: a simple Linux server, fortunately well
connected, with tools I can easily install and administer. JSPWiki seems
such a tool to me. After my holidays I will investigate how I can
republish the stored Wiki pages as xdoc XML *through* Cocoon using some
decent skin, as a testcase to migrate Wiki content to xdocs in CVS.
CocoDocoWiki should primarily be used by the documentation contributors,
not necessarily by the community at large - there exist people in our
community that are able and willing to graduate Wiki docs to real Cocoon
documentation.
All this talk about logistics is boring me to death. There was the issue
of not being able to persist [RT]s using some Wiki-like website. So Andy
and I investigated whether we could host such a website. Then Leigh
jumped up with loads of doco contribs. I consider this rapid advancement
of content- and process-related matters much more important than the
technology being used.
The marketing-savvy people will also fail to adopt Cocoon if there isn't
any good documentation with it. So let's stop discussing the 'how', and
focus on the 'what'.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ulrich Mayring wrote:
> Andrew C. Oliver wrote:
>
>> Personally.... I feel content is king. The rest is details. Lets
>> start generating more content..then we'll figure out how to organize
>> it, and then figure out the technical details (which often seem to
>> become the focus....but this is WRONG)
>
>
> Generally I would agree with you. But as with all good rules, there
> are exceptions. Content is NOT king, when there is not at least a
> basic presentation layer and a sense of "we practice what we preach"
> aka "proof of concept".
>
> When Cocoon first started out, many people got excited and went to
> coding. But no-one could be bothered to use this new tool for the most
> basic purpose: to serve its own website. Even today, generations and
> generations of code later, Cocoon does not serve its own website. And
> now it does not serve its own Wiki.
>
> People from outside ask: what kind of web publishing technology cannot
> even serve its own website? And, Cocoon wants to replace JSP, but it
> uses JSPWiki?
>
> I'm sure there are good reasons, but from a marketing point of view
> this is a show-stopper. It gives the impression that Cocoon is so hard
> to use that even the devs themselves prefer lighter tools.
So you'd rather have NO documentation than serve it on un-cool tools?
As for why Cocoon doesn't serve its own website, I think that has more
to do with the fact Apache has
SEVERAL projects to serve websites and *few* servers doing it. If EVER
project that CAN served its
own website, we'd need some new hardware.
Anyhow, the wiki has been set up outside project resources. The only
resolve those who object really have is
not to use it. Which is unfortunate but your choice. I applaud the
setup of this wiki and plan to contribute!
-Andy
>
> Ulrich
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Andrew C. Oliver wrote:
> Personally.... I feel content is king. The rest is details. Lets
> start generating more content..then we'll figure out how to organize it,
> and then figure out the technical details (which often seem to become
> the focus....but this is WRONG)
Generally I would agree with you. But as with all good rules, there are
exceptions. Content is NOT king, when there is not at least a basic
presentation layer and a sense of "we practice what we preach" aka
"proof of concept".
When Cocoon first started out, many people got excited and went to
coding. But no-one could be bothered to use this new tool for the most
basic purpose: to serve its own website. Even today, generations and
generations of code later, Cocoon does not serve its own website. And
now it does not serve its own Wiki.
People from outside ask: what kind of web publishing technology cannot
even serve its own website? And, Cocoon wants to replace JSP, but it
uses JSPWiki?
I'm sure there are good reasons, but from a marketing point of view this
is a show-stopper. It gives the impression that Cocoon is so hard to use
that even the devs themselves prefer lighter tools.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Personally.... I feel content is king. The rest is details. Lets
start generating more content..then we'll figure out how to organize it,
and then figure out the technical details (which often seem to become
the focus....but this is WRONG)
-Andy
Diana Shannon wrote:
>
> On Tuesday, August 6, 2002, at 04:32 PM, Leigh.Dodds@ingenta.com wrote:
>
>> As far as QA goes, I'd suggest this be applied to Wiki content to
>> make 'official docs', but you can still point people at the Wiki
>> for information, and say "here be dragons".
>
>
> But making "official" cvs xdocs from the wiki still seems like a PITA
> -- at least at the moment. Why not wrap a decent skin on the wiki
> site, do periodic QA, and dump the periodic result (html docs?) into
> the cvs/web site for distros/snapshots, etc. Why do we need cvs xdocs
> anymore?
>
> -- Diana (suddenly feeling very liberated)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> Apparently ;-)
>
> Seriously, I think we will have both, but perhaps for different reasons:
>
> * Wiki for document creation and collaboration, for [RT] sharing and
> the like
> * xdocs for reference documentation, in-sync with releases/branches,
> incorporating Javadoc, etc etc
>
> Don't forget Wikis have no hierarchy (except as made apparent through
> hyperlinkage), all Wiki docs are stored in one directory and are not
> very well organized serverside (which is the purpose, of course)
>
> I see CocoDocoWiki as a breeding pool, and grown-up fishes can then
> migrate to xdoc heaven ;-)
>
> </Steven>
+1 - And later when we have lots and lots of documentation in the Wiki
and its a problem, we can think about Cool Tool X. But until then...
Developing Cool Tool X is like driving a Battleship through a small canal.
-andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
> On Tuesday, August 6, 2002, at 04:32 PM, Leigh.Dodds@ingenta.com wrote:
>
>> As far as QA goes, I'd suggest this be applied to Wiki content to
>> make 'official docs', but you can still point people at the Wiki
>> for information, and say "here be dragons".
>
>
> But making "official" cvs xdocs from the wiki still seems like a PITA --
> at least at the moment. Why not wrap a decent skin on the wiki site, do
> periodic QA, and dump the periodic result (html docs?) into the cvs/web
> site for distros/snapshots, etc. Why do we need cvs xdocs anymore?
>
> -- Diana (suddenly feeling very liberated)
Apparently ;-)
Seriously, I think we will have both, but perhaps for different reasons:
* Wiki for document creation and collaboration, for [RT] sharing and the
like
* xdocs for reference documentation, in-sync with releases/branches,
incorporating Javadoc, etc etc
Don't forget Wikis have no hierarchy (except as made apparent through
hyperlinkage), all Wiki docs are stored in one directory and are not
very well organized serverside (which is the purpose, of course)
I see CocoDocoWiki as a breeding pool, and grown-up fishes can then
migrate to xdoc heaven ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, August 6, 2002, at 04:32 PM, Leigh.Dodds@ingenta.com wrote:
> As far as QA goes, I'd suggest this be applied to Wiki content to
> make 'official docs', but you can still point people at the Wiki
> for information, and say "here be dragons".
But making "official" cvs xdocs from the wiki still seems like a PITA --
at least at the moment. Why not wrap a decent skin on the wiki site, do
periodic QA, and dump the periodic result (html docs?) into the cvs/web
site for distros/snapshots, etc. Why do we need cvs xdocs anymore?
-- Diana (suddenly feeling very liberated)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Le...@ingenta.com.
> True, but on cocoon-users, there are some great threads which yield good
> doc material.
There certainly are, and I'd hope this could be captured in the Wiki.
> The problem now is a lack of doc committers and patches
> from volunteers.
Lowering the barrier to entry (making it easy to submit content, add
corrections, etc may resolve this)
> Perhaps we should be encouraging users to post their
> summaries in a wiki-like grammar on cocoon-users.
Why not directly into the Wiki?
> I guess the quality of
> doc-oriented wikis will depend in part if uber-knowledgeable people,
> like Vadim, Christian, and others, spend time monitoring/editing
> doc-wikis like they do currently on cocoon-users. Since Vadim started
> this wiki topic, sounds like he'll be visiting it??? Seems to me we'd
> need a QA stage before commits to cvs.
Can't claim to be uber-knowledgeable, but I'll certainly be keeping an eye on
Steven's Wiki, I've just added a chunk of content, as you can see:
http://outerthought.net/wiki/Wiki.jsp?page=RecentChanges
One thing I like about JSPWiki is that it has an RSS feed, so you can
monitor changes to the site with an RSS reader right from your
desktop, you don't have to keep trawling through the site.
As far as QA goes, I'd suggest this be applied to Wiki content to
make 'official docs', but you can still point people at the Wiki
for information, and say "here be dragons".
> Yes, but in some ways, **until** we can transform Wiki content into a
> structure based on document.dtd, etc., isn't this a step backwards for
> some of the more complex-structured docs?
You can do this with WikiML (http://www.wikiml.org) amongst other things.
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, August 6, 2002, at 02:24 PM, Steven Noels wrote:
>>
>> Writing on a wiki is also different from writing on a mailing list : on
>> a ML, you can throw an idea in a few lines and see if you get some
>> feedback.
True, but on cocoon-users, there are some great threads which yield good
doc material. The problem now is a lack of doc committers and patches
from volunteers. Perhaps we should be encouraging users to post their
summaries in a wiki-like grammar on cocoon-users. I guess the quality of
doc-oriented wikis will depend in part if uber-knowledgeable people,
like Vadim, Christian, and others, spend time monitoring/editing
doc-wikis like they do currently on cocoon-users. Since Vadim started
this wiki topic, sounds like he'll be visiting it??? Seems to me we'd
need a QA stage before commits to cvs.
>> On a wiki, your thoughts have to be more cleanly structured in
>> order to be presented. This also helps maturing ideas.
>>
Yes, but in some ways, **until** we can transform Wiki content into a
structure based on document.dtd, etc., isn't this a step backwards for
some of the more complex-structured docs? In other words, it seems it
could significantly increase the burden on committers making periodic
updates to cvs, etc. I also worry a bit about managing links introduced
by Wiki docs. Link troubleshooting already consumes a huge chunk of my
volunteer time. Sorry if this is an stupid question, but can Wikis check
links (included in submitted content)?
> A wiki for RT's would be really, really great.
I think we should seriously consider doing individual FAQs/Topics this
way, i.e., one page for each FAQ/Topic.
> Do I proceed with my setup?
Would this now become a Forrest sub-project? Will doc committers have
access to the resources/files they need?
Syvain, how's http://www.anyware-tech.com/wikiland/ faring?
-- Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org