You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/08/05 14:57:46 UTC
[RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization
(Cocoon plugins))
Andrew C. Oliver wrote:
>>
>> If nobody objects, I will branch on 7 August 2002 and start refactoring.
>>
> Not that my opinion should count for much, but I object. My objection
> is this. Before there is an agreement and set of documentation
> explaining "WHAT goes WHERE" then this will be contentious. Secondly,
> I'd like to see something that explains how a common person will go
> about installing Cocoon with *feature X* once its split into a billion
> complex pieces with UNKNOWN dependancies.
Each module will be a "project" in the Gump descriptor.
Hence the dependencies are clear.
> Modularization will only work
> if the modules are defined in a human language.
Exactly.
> So far I see a million
> "lets fix it via just hacking at it" approaches, no definitions, and
> still inadequate documentation. Personally, I feel the documentation is
> FAR more important than ANY refactoring at helping users understand Cocoon.
But how can you document a tangle? By writing tangled documentation, as now.
We need to get a cleaner separation of stuff and that is gonna be
documented.
I will hack on the branch so that others can see the moves, and they
will be discussed as they are done.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Leigh Dodds wrote:
>
>>> Since we are talking about code, CVS logs are our WIKI.
>>> That's the intention.
>>
>>
>>
>> You're not serious?
>> I'm not talking about file level changes, I'm talking about design
>> documents, project roadmaps, proposals, etc. How do they get put into
>> a CVS log?
>
>
> I commit the change, it gets reviewed there, live.
> If I want to make a document I commit it, and others change it, I get
> notified via log, I change again or discuss, etc.
>
> I don't see what a WIKI brings developers more than VCSes.
>
It does.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 05 August 2002 16:46, Andrew C. Oliver wrote:
>. . .
> If no, would you all like me to set this up on my server, and if its
> successful we'll move it to some place bigger?
+1
There have been talks of having a wiki for Cocoon for a while, it would
certainly be good for both developers and "documentors". Much more efficient
than a mailing list when collaborating on specs or documentation IMHO.
(There is wikiland which runs on Cocoon, but I don't know how far it is in
its development. Right now the server at
http://www.anyware-tech.com/wikiland/ seems to be down).
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Do we (Apache) have a server to set this up on?
If no, would you all like me to set this up on my server, and if its
successful we'll move it to some place bigger?
-Andy
Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Leigh Dodds wrote:
>>
>>
>>>>Since we are talking about code, CVS logs are our WIKI.
>>>>That's the intention.
>>>>
>>>>
>>>You're not serious?
>>>
>>>I'm not talking about file level changes, I'm talking about design
>>>
>>>
>>documents,
>>
>>
>>>project roadmaps, proposals, etc. How do they get put into a CVS
>>>
>>>
>log?
>
>
>>I commit the change, it gets reviewed there, live.
>>If I want to make a document I commit it, and others change it, I get
>>notified via log, I change again or discuss, etc.
>>
>>I don't see what a WIKI brings developers more than VCSes.
>>
>>
>
>Nicola,
>
>I think you missed the point. We have lots of RTs, discussions, etc, and
>the only way to get them is through archives, or sometimes some good
>soul [summary]izes them, and again, these summaries are available in the
>archive. Wiki will allow to keep this information online, browsable, and
>*editable*.
>
>
>You are not proposing to use CVS instead of mail-list, are you? ;)
>
>Vadim
>
>
>
>---------------------------------------------------------------------
>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: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Diana Shannon <sh...@apache.org>.
On Monday, August 5, 2002, at 10:52 AM, Leigh Dodds wrote:
>
>> I think you missed the point. We have lots of RTs, discussions, etc,
>> and
>> the only way to get them is through archives, or sometimes some good
>> soul [summary]izes them, and again, these summaries are available in
>> the
>> archive. Wiki will allow to keep this information online, browsable,
>> and
>> *editable*.
>
> Yep thats exactly what I meant.
>
> Wikis are a 'step up' from a mailing list archive because they have a
> low barrier to entry (it's just as easy to click 'edit this page' as it
> is to click 'new msg'), but there's the ability to go back and revise
> documents. E.g. to add more information, mark stuff as implemented
> or rejected, rationale behind decisions, etc.
I agree. If we have the resources available we should try **any**
approach that increases doc/author input. Even better if such a wiki
system includes (or we can add on) a structured text -> xml tool (based
on new document dtds?). Converting even well-summarized email posts into
cvs doc commits still takes an overly large amount of commiter time. I'm
really not an experienced wiki person, so I'm sure I'm missing out on
many ways to make my volunteer time more productive.
Still, we're starting to get great input on cocoon-users related to doc
content. The doc list (just recently formed) is getting some traffic; I
believe it serves a different purpose -- doc discussions, not simply
editing/changing. Wiki could become another great tool, but let's keep
all of our options open and continue to encourage all efforts, however
they manifest.
> I've personally being organising my Cocoon notes into a wiki I
> have running locally -- something which I'm hoping to release
> publically soon.
Great.
> Some of it can easily be converted into HOW-TOs and other snippets
> which I'll send to Diana as soon as I get time.
I'd love to know more about this "easy" conversion process. And thanks
for the doc draft, Leigh, along with your other helpful
developerWorks-hosted tutorials! Thanks also to Andy, for offering to
host such a system.
-- Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: 05 August 2002 15:37
> To: cocoon-dev@xml.apache.org; nicolaken@apache.org
> Subject: RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon
> Organization(Cocoonplugins))
> ...
> I think you missed the point. We have lots of RTs, discussions, etc, and
> the only way to get them is through archives, or sometimes some good
> soul [summary]izes them, and again, these summaries are available in the
> archive. Wiki will allow to keep this information online, browsable, and
> *editable*.
Yep thats exactly what I meant.
Wikis are a 'step up' from a mailing list archive because they have a
low barrier to entry (it's just as easy to click 'edit this page' as it
is to click 'new msg'), but there's the ability to go back and revise
documents. E.g. to add more information, mark stuff as implemented
or rejected, rationale behind decisions, etc.
I've personally being organising my Cocoon notes into a wiki I
have running locally -- something which I'm hoping to release
publically soon.
It contains all the notes I made whilst writing up my three Cocoon
tutorials with developerWorks, so there's a fair chunk of content there.
Hopefully everyone can benefit from it.
Some of it can easily be converted into HOW-TOs and other snippets
which I'll send to Diana as soon as I get time.
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Leigh Dodds wrote:
> >>Since we are talking about code, CVS logs are our WIKI.
> >>That's the intention.
> >
> >
> > You're not serious?
> >
> > I'm not talking about file level changes, I'm talking about design
> documents,
> > project roadmaps, proposals, etc. How do they get put into a CVS
log?
>
> I commit the change, it gets reviewed there, live.
> If I want to make a document I commit it, and others change it, I get
> notified via log, I change again or discuss, etc.
>
> I don't see what a WIKI brings developers more than VCSes.
Nicola,
I think you missed the point. We have lots of RTs, discussions, etc, and
the only way to get them is through archives, or sometimes some good
soul [summary]izes them, and again, these summaries are available in the
archive. Wiki will allow to keep this information online, browsable, and
*editable*.
You are not proposing to use CVS instead of mail-list, are you? ;)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leigh Dodds wrote:
>>Since we are talking about code, CVS logs are our WIKI.
>>That's the intention.
>
>
> You're not serious?
>
> I'm not talking about file level changes, I'm talking about design documents,
> project roadmaps, proposals, etc. How do they get put into a CVS log?
I commit the change, it gets reviewed there, live.
If I want to make a document I commit it, and others change it, I get
notified via log, I change again or discuss, etc.
I don't see what a WIKI brings developers more than VCSes.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
> Since we are talking about code, CVS logs are our WIKI.
> That's the intention.
You're not serious?
I'm not talking about file level changes, I'm talking about design documents,
project roadmaps, proposals, etc. How do they get put into a CVS log?
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoon
plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leigh Dodds wrote:
>>HA! And we'll be in exactly the same situation in the end. I'm sorry
>>but more doing things by the seat of our pants
>>without explaining it in honest to god documentation first (and
>>documents can be modified as your understanding develops) is
>>a fools errand. We'll just have the same thing broken into many pieces
>>that very few people understand. This is not an
>>improvement in my opinion. (Like I said, it shouldn't count for much,
>>I'm 3/4 very dumb user and 1/4 cocoon developer)
>
>
> Here's a concrete suggestion: start a Cocoon wiki site.
>
> Put all proposals in there, as they get implemented fill in the details.
> This can still be developer-oriented docs (i.e. no tutorials), but
> at least it's captured.
>
> Yep, I know there are web archives, but they're not a great way
> of organising information. Wikis are the next step up.
Since we are talking about code, CVS logs are our WIKI.
That's the intention.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoon plugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
> HA! And we'll be in exactly the same situation in the end. I'm sorry
> but more doing things by the seat of our pants
> without explaining it in honest to god documentation first (and
> documents can be modified as your understanding develops) is
> a fools errand. We'll just have the same thing broken into many pieces
> that very few people understand. This is not an
> improvement in my opinion. (Like I said, it shouldn't count for much,
> I'm 3/4 very dumb user and 1/4 cocoon developer)
Here's a concrete suggestion: start a Cocoon wiki site.
Put all proposals in there, as they get implemented fill in the details.
This can still be developer-oriented docs (i.e. no tutorials), but
at least it's captured.
Yep, I know there are web archives, but they're not a great way
of organising information. Wikis are the next step up.
Cheers,
L.
--
Leigh Dodds
http://weblogs.userland.com/eclectic
"Pluralitas non est ponenda sine necessitate" -- William of Ockham
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization
(Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Andrew C. Oliver wrote:
>
>>>
>>> If nobody objects, I will branch on 7 August 2002 and start
>>> refactoring.
>>>
>> Not that my opinion should count for much, but I object. My
>> objection is this. Before there is an agreement and set of
>> documentation explaining "WHAT goes WHERE" then this will be
>> contentious. Secondly, I'd like to see something that explains how a
>> common person will go about installing Cocoon with *feature X* once
>> its split into a billion complex pieces with UNKNOWN dependancies.
>
>
> Each module will be a "project" in the Gump descriptor.
> Hence the dependencies are clear.
Thats a cop out.
>
>> Modularization will only work if the modules are defined in a human
>> language.
>
>
> Exactly.
Lets START there.
>
>> So far I see a million "lets fix it via just hacking at it"
>> approaches, no definitions, and still inadequate documentation.
>> Personally, I feel the documentation is FAR more important than ANY
>> refactoring at helping users understand Cocoon.
>
>
> But how can you document a tangle? By writing tangled documentation,
> as now.
That is false. The state of the documentation is not related to the
state of Cocoon, its related to the low priority that documentation is
given. Example:
http://jakarta.apache.org/poi/poifs/fileformat.html
The OLE 2 Compound Document format is more of a tangle than Cocoon could
ever hope to be. Yet this documentation is organized and conceise. Can
you read this and immediately grasp the low level concepts and just hack
one out? No probably
not, you'd need the experience of working with it. But can you get a
high level conceptual understanding and know where to start? Yes.
There are innumerable examples of this throughout history, but I'm not
that long winded. Read some Stephen Hawkings and understand the order
of the chaotic birth of the universe explained conciecely without making
a web of chaos! (And I'm mathmatically retarded)
>
> We need to get a cleaner separation of stuff and that is gonna be
> documented.
No that is exactly the opposite. We need a clear understanding of what
is going to be seperated before we
do it. Otherwise it will be more of the same.
>
> I will hack on the branch so that others can see the moves, and they
> will be discussed as they are done.
>
HA! And we'll be in exactly the same situation in the end. I'm sorry
but more doing things by the seat of our pants
without explaining it in honest to god documentation first (and
documents can be modified as your understanding develops) is
a fools errand. We'll just have the same thing broken into many pieces
that very few people understand. This is not an
improvement in my opinion. (Like I said, it shouldn't count for much,
I'm 3/4 very dumb user and 1/4 cocoon developer)
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org