You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Crossley <cr...@indexgeo.com.au> on 2003/11/28 03:46:05 UTC
Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Stefano Mazzocchi wrote:
> Reinhard Poetz wrote:
>
> > ok, is there a way for others to help you or in other words:
> > do you need some help?
>
> No, I move faster if I do stuff myself. There is no much code to write,
> just a lot of glue and finding out the pieces of the puzzle and working
> with somebody else is going to slow this down in prototypical phase.
>
> After the prototype is ready, there will be *tons* of polishing to do,
> but I want to create the itches first, so that all of us can scratch
> later.
Mmmm, i am not sure that i like this approach. "Doco" sounds
to me like one of the reasons that "Forrest" was started.
What is worrying is that this one-person thing (though i trust
Stefano to know what to do) will have no community to land in
and Apache will spawn yet another new project.
I don't mean to be cynical or anything, but Linotype and Portal
landed in Cocoon as more-or-less functional things and not much
has happened since.
I know that there is a trade-off between too much talk and not
enough doing. However, without any discussion there is a risk
that something fundamental will be missed.
--David
Re: Linotype and RealPathModule
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.12.2003 12:17, Stefano Mazzocchi wrote:
>> From a logical view the new behaviour of Jetty makes sense, at least
>> for consistency:
>>
>> / D:\cocoon-2.1\build\webapp
>> /images D:\cocoon-2.1\build\webapp\images
>> /WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
>>
>> while it was "D:\cocoon-2.1\build\webapp\" until now.
>
>
> that's probably why they fixed it.
>
>> Shall we remove all trailing path separators?
>
>
> what is the behavior of tomcat? that is considered the reference
> implementation.
Unfortunately "D:\cocoon-2.1\build\webapp\".
So it's more a simple root + accessor:
root = "D:\cocoon-2.1\build\webapp"
accessor value
/ D:\cocoon-2.1\build\webapp\
/images D:\cocoon-2.1\build\webapp\images
/WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
Hmm, also not that illogical.
I suggest to always remove the trailing path separator in the
RealPathModule. Any comments?
Joerg
Re: Linotype and RealPathModule (was: Doco needs landing)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 2 Dec 2003, at 03:52, Joerg Heinicke wrote:
> On 29.11.2003 17:02, Stefano Mazzocchi wrote:
>
>>> I don't mean to be cynical or anything, but Linotype and Portal
>>> landed in Cocoon as more-or-less functional things and not much
>>> has happened since.
>> wait a full second, David. I can't talk for Portal-oriented stuff
>> since I don't use it, but for linotype, it was ported to be
>> IE5/mozilla cross-platform, I received a few patches and Joerg is
>> patching it to fix jetty problems and there were discussions about
>> integration with cocoon forms and Lenya.
>
> Did I promised it? :-)
>
> I recommended Linotype to two persons here managing their private club
> website news. Otherwise these both persons (= software developer) have
> to do all the changes in static HTML pages, at least this way it was
> done until now. If they choose this approach (what about hosting and
> so on ...) the editor base is bigger, less work for them. So Linotype
> is not unused or dead - it works. Probably nothing will come back to
> Cocoon from these two persons, but who knows - bug reports are also
> welcome.
The plan is to move the xhtml editing behavior in Cocoon Forms. That
will give a lot more exposure and potentially more bug reports, feature
requests and patches.
> The problem with the realpath I came across when testing the first
> trials (they worked on one system, but not on another one - endorsed
> libs again). I have no problem fixing the realpath problem using my
> pseudo code (if !ends with '/') and so on, but I would like to know
> what's correct in the servlet spec sense? I read across it, but didn't
> find any further mentioning besides realpath exists. Do Tomcat and
> Jetty 4.2.9 behave correctly or Jetty 4.2.14? And is it something to
> be fixed in Linotype or in the realpath module? I don't want to add a
> simple hack to circumvent other's problems.
>
> From a logical view the new behaviour of Jetty makes sense, at least
> for consistency:
>
> / D:\cocoon-2.1\build\webapp
> /images D:\cocoon-2.1\build\webapp\images
> /WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
>
> while it was "D:\cocoon-2.1\build\webapp\" until now.
that's probably why they fixed it.
> Shall we remove all trailing path separators?
what is the behavior of tomcat? that is considered the reference
implementation.
--
Stefano.
Linotype and RealPathModule (was: Doco needs landing)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.11.2003 17:02, Stefano Mazzocchi wrote:
>> I don't mean to be cynical or anything, but Linotype and Portal
>> landed in Cocoon as more-or-less functional things and not much
>> has happened since.
>
>
> wait a full second, David. I can't talk for Portal-oriented stuff since
> I don't use it, but for linotype, it was ported to be IE5/mozilla
> cross-platform, I received a few patches and Joerg is patching it to fix
> jetty problems and there were discussions about integration with cocoon
> forms and Lenya.
Did I promised it? :-)
I recommended Linotype to two persons here managing their private club
website news. Otherwise these both persons (= software developer) have
to do all the changes in static HTML pages, at least this way it was
done until now. If they choose this approach (what about hosting and so
on ...) the editor base is bigger, less work for them. So Linotype is
not unused or dead - it works. Probably nothing will come back to Cocoon
from these two persons, but who knows - bug reports are also welcome.
The problem with the realpath I came across when testing the first
trials (they worked on one system, but not on another one - endorsed
libs again). I have no problem fixing the realpath problem using my
pseudo code (if !ends with '/') and so on, but I would like to know
what's correct in the servlet spec sense? I read across it, but didn't
find any further mentioning besides realpath exists. Do Tomcat and Jetty
4.2.9 behave correctly or Jetty 4.2.14? And is it something to be fixed
in Linotype or in the realpath module? I don't want to add a simple hack
to circumvent other's problems.
From a logical view the new behaviour of Jetty makes sense, at least
for consistency:
/ D:\cocoon-2.1\build\webapp
/images D:\cocoon-2.1\build\webapp\images
/WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
while it was "D:\cocoon-2.1\build\webapp\" until now.
Shall we remove all trailing path separators?
Joerg
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 2 Dec 2003, at 11:03, Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote:
>> On 1 Dec 2003, at 08:26, Nicola Ken Barozzi wrote:
>>> What I don't really understand is that he is not using a public
>>> Apache repository, like the Cocoon scratchpad, to do it.
>> I am!!!
>
> Yes, sorry for misunderstanding.
>
> As I tried to say I'm +1 to your work all the way, and was just
> puzzled by the apparent closeness of the code. I'm happy to be proved
> wrong.
:-)
> Stefano Mazzocchi wrote:
>
> > On 1 Dec 2003, at 15:01, Nicola Ken Barozzi wrote:
> >
> >> I think that creating a doco@apache.org mailing list, similar to
> >> repository@apache.org could create a nice space where all these
> >> projects and even others can discuss things without cross posting.
> >
> > not yet. it's too much vaporware now. I shouldn't have come up with
> > the plan before having something to show.
> >
> > Damn me.
>
> Well, you let the cat out of the bag, and IMHO if you keep on saying
> "I'm working on it" this discussion, that has now been cleared, will
> probably and unfortunately start again.
Very true. I'll shut up until I have something to show ;-)
> Why don't you add "Doco" to this page http://cvs.apache.org/~stefano/
> with a reference to the JSPwiki page about it? At least we have
> something to point to when others ask.
I will do that.
> Thanks for your work on it, it's really really appreciated. :-)
You are welcome. The more serious rationale behind this will come up
soon, but hey, no more cats out of the bags for now ;-)
--
Stefano.
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 1 Dec 2003, at 08:26, Nicola Ken Barozzi wrote:
>
>> What I don't really understand is that he is not using a public Apache
>> repository, like the Cocoon scratchpad, to do it.
>
> I am!!!
Yes, sorry for misunderstanding.
As I tried to say I'm +1 to your work all the way, and was just puzzled
by the apparent closeness of the code. I'm happy to be proved wrong.
Stefano Mazzocchi wrote:
> On 1 Dec 2003, at 15:01, Nicola Ken Barozzi wrote:
>
>> I think that creating a doco@apache.org mailing list, similar to
>> repository@apache.org could create a nice space where all these
>> projects and even others can discuss things without cross posting.
>
> not yet. it's too much vaporware now. I shouldn't have come up with
> the plan before having something to show.
>
> Damn me.
Well, you let the cat out of the bag, and IMHO if you keep on saying
"I'm working on it" this discussion, that has now been cleared, will
probably and unfortunately start again.
Why don't you add "Doco" to this page http://cvs.apache.org/~stefano/
with a reference to the JSPwiki page about it? At least we have
something to point to when others ask.
Thanks for your work on it, it's really really appreciated. :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 08:26, Nicola Ken Barozzi wrote:
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it.
I am!!! I'm sending back the patches to slide everytime I make one. I
was nominated for committership in Slide and hopefully I will be voted
in.
Next step is the repository block and this happens here in cocoon. I
already sent an email about it.
Doco is growing bottom up.
After the repository block is done, I plan to move Linotype to use the
repository block and the code will get back in cocoon cvs.
After that, I plan to move the xhtml editor of linotype into Cocoon
Forms. This will happen in cocoon cvs again.
then will move lenya to use cocoon forms and flow, this will happen in
lenya cvs (but probably on a branch or /proposal/ not to stop lenya
from growing)
then will write the mailets for the mail workflow, this will happen in
james cvs (but I'm not committer there)
etc.. etc..
please understand that I'm doing everything in the open. I'll try to
come up with a "implementation plan" so that people know what stage I
am in... but the problem is that each stage depends on the previous, so
there is no parallelization possible... this is why I said separating
phases is going to slow things down. there is not much code to write,
it's already there, it just needs to be polished.
but there is *NO* single line of code that isn't already back in the
CVS repositories or is going to be there.
Doco is still a long way, people. We have the pieces, but they are
rough, we need to polish them first. and this is what I'm doing. One
piece at the time.
--
Stefano.
Re: Doco needs landing
Posted by Steven Noels <st...@outerthought.org>.
On Dec 1, 2003, at 2:14 PM, David Crossley wrote:
> Nicola Ken Barozzi wrote:
>>> David Crossley wrote:
>> ...
>>>> What is worrying is that this one-person thing (though i trust
>>>> Stefano to know what to do) will have no community to land in
>>>> and Apache will spawn yet another new project.
>>
>> Well, Doco ahould be a glue that it to put together different projects
>> in a coherent vision. We have Slide (backend), Lenya (CMS), Forrest
>> (presentation).
>
> It sounds like it will be a new project outside of the
> Cocoon/Slide/Lenya/Forrest projects. Fair enough, that might
> be the best solution. But where is the planning to enable that?
There is none, at least not in a formalized sense, but that shouldn't
be a problem. I'm currently balancing between a) we should require
every more-than-trivial code donation to go through the Incubator, not
for IP issues (which I doubt would ever emerge from our own dear
Stefano), but to make sure community-building is not an afterthought,
and b) "OK, let's see what Darwin does with it" attitude. Planning
won't help much, IMHO, it's just the PMC which needs to decide which
way it wants to go: do we need more code a possibly interested
community could come for and play with, or do we try to flesh out a
community before, which might ensure a better longevity of the code.
Either case, I still believe things just happen, and we should be
reactive and decisive enough to make the best out of this, by actively
(re)structuring the Cocoon project (as a whole) towards optimal
community cohesion, while still providing breathing space for the
different subcommunities.
The fact Doco has an ASF-wide appeal doesn't simplify this equation,
although to its own benefit IMHO. Forrest is technically also
intricately linked to Cocoon, still its community of users is wildly
different - so offering cross-codebase commit access was perhaps the
better idea rather than actively trying to subsume Forrest in the
Cocoon hemisphere. Ditto with Doco: it might be linked to Cocoon, if
only by its creator, and no doubt also because of technical reasons,
but still it might warrant its own development community in the future.
Frankly, I think we should get our act together on other issues (Rhino
reintegration, Fortress, Blocks 2.2, project guidelines, splitting of
some blocks in effective subprojects, and some light weeding of code
cruft) before trying to grow the Cocoon organizational structure beyond
what we have now (by providing anything else than a technical landing
zone for Doco). But that's IMHO and just my intellectual exercise -
please take it as is.
Also, I think Stefano just needs a bit more time to come up with
something sufficiently designed and fleshed out so that others *can*
collaborate on it, which is exactly the same as happened with Woody:
there were three, maybe four weeks of intense, behind-closed-doors and
silent thinking, designing and coding, before there was a first code
drop in the public repository. I'm not going to evangelize this method
of contributing for all future contributions, but sometimes people need
to be able to get down with their head and get some real work done, in
order to let others join successfully. This, IMHO, is the holy grail of
Open Source development: moving forward while not claiming the entire
"thoughtspace" and design, so that others feel both welcome *and*
capable to join.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Doco needs landing
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 15:01, Nicola Ken Barozzi wrote:
> I think that creating a doco@apache.org mailing list, similar to
> repository@apache.org could create a nice space where all these
> projects and even others can discuss things without crossposting.
not yet. it's too much vaporware now. I shouldn't have come up with the
plan before having something to show.
Damn me.
--
Stefano.
Re: Doco needs landing
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>>David Crossley wrote:
...
> My concern was not necessarily that Forrest should be doing it,
> but rather that Forrest was born to do that, then lost its people,
> then had to modify its dreams. Let us get it right this time.
Well, this is not exactly how I see it. Forrest lost its people? Where?
What happened IMHO is that the frontend part was so "big" to do properly
that Forrest had to simply concentrate on that. The rest came by itself,
and we are still concentrating on that part. With afterthought it seems
logical that there is a core group that concentrates on what Forrest now
is doing.
...
> The initial proposal was copied to many different
> lists and it is hard to follow.
Hmmm...
...
> You say "land here" .... Where? In Cocoon? Is it just a block maybe?
Till I see it, I really can't say.
In any case, this is Stefano's tentative. If it fails (and I don't think
it will), others can easily try again. If others want to give him a hand
say so, and he will surely use some help. Personally I don't have time
and motivation to do what he is doing, nor the skill actually, so from
my POV whatever he does is ok, and I'll just see what to do when it
"lands". I could see a problem if/when others want to actively help but
even after asking him cannot, but I don't see this happening.
I think that creating a doco@apache.org mailing list, similar to
repository@apache.org could create a nice space where all these projects
and even others can discuss things without crossposting.
For example Stefano could use it to post advancements of his efforts or
make cross-list questions.
Whattadathink?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> >David Crossley wrote:
> ...
> >> What is worrying is that this one-person thing (though i trust
> >> Stefano to know what to do) will have no community to land in
> >> and Apache will spawn yet another new project.
>
> Well, Doco ahould be a glue that it to put together different projects
> in a coherent vision. We have Slide (backend), Lenya (CMS), Forrest
> (presentation).
It sounds like it will be a new project outside of the
Cocoon/Slide/Lenya/Forrest projects. Fair enough, that might
be the best solution. But where is the planning to enable that?
> Look at the Forrest community now. Do you think we are ready and willing
> to lead such a design? Speaking for me, not now, I still have lots of
> work to do on what Forrest does now.
My concern was not necessarily that Forrest should be doing it,
but rather that Forrest was born to do that, then lost its people,
then had to modify its dreams. Let us get it right this time.
Anyway, the Forrest community really does have all the Cocoon
committers too. So it could be done there if that was the
appropriate place.
> To be honest, Stefano has already told us about it and already got
> feedback from all these projects, so in fact he is already working with
> our ACK. Furthermore, there is no decision yet about where to place it,
> or even if it will ever be something autonomous.
That was what i was getting at in the beginning of this thread.
Where will it live? Where can we talk about it and help to guide
and build it? The initial proposal was copied to many different
lists and it is hard to follow.
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it. At least we could have
> watched it grow, and he would have not been "slowed" with "community" as
> he now likes to say ;-) In any case, he's free to do so if he wishes,
> and we will see what to do when this thing will land here.
You say "land here" .... Where? In Cocoon? Is it just a block maybe?
--David
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 09:16, Gianugo Rabellino wrote:
> Nicola Ken Barozzi wrote:
>
>> What I don't really understand is that he is not using a public
>> Apache repository, like the Cocoon scratchpad, to do it. At least we
>> could have watched it grow, and he would have not been "slowed" with
>> "community" as he now likes to say ;-) In any case, he's free to do
>> so if he wishes, and we will see what to do when this thing will land
>> here.
>
> I understand that there is no such thing as code now. From a few
> online/RL chats and the emails I'm reading, I gather that until now
> Stefano has been busy testing all the possible DAV server/client
> combinations on earth, patching them and earning committership on
> Slide while at it :-), but so far with not a single Cocoon-specific
> line of code. I'm pretty sure that as soon as there is something more
> Cocoon related we'll start to see RTs (we already had one yesterday)
> and code.
Precisely!!!
BTW, just in order to choose which repository to use and to invest my
effort on, I spent a few weeks.
This might not get you a single line of code, but might benefits other
people and polarize communities toward a common goal.
If this is not useful, I don't know what is.
--
Stefano.
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Gianugo Rabellino <gi...@apache.org>.
Nicola Ken Barozzi wrote:
>
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it. At least we could have
> watched it grow, and he would have not been "slowed" with "community" as
> he now likes to say ;-) In any case, he's free to do so if he wishes,
> and we will see what to do when this thing will land here.
>
I understand that there is no such thing as code now. From a few
online/RL chats and the emails I'm reading, I gather that until now
Stefano has been busy testing all the possible DAV server/client
combinations on earth, patching them and earning committership on Slide
while at it :-), but so far with not a single Cocoon-specific line of
code. I'm pretty sure that as soon as there is something more Cocoon
related we'll start to see RTs (we already had one yesterday) and code.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Michael Wechner wrote:
> Nicola Ken Barozzi wrote:
>
...
[about doco]
> it's not CVS or SVN yet, but AFAIK Stefano updated recently
>
> http://wiki.cocoondev.org/Wiki.jsp?page=Doco
Excellent! :-)
Thanks Michael for reporting.
And thanks Stefano for writing it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Michael Wechner <mi...@wyona.com>.
Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote:
>
>> On 28 Nov 2003, at 03:46, David Crossley wrote:
>
>
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it.
it's not CVS or SVN yet, but AFAIK Stefano updated recently
http://wiki.cocoondev.org/Wiki.jsp?page=Doco
HTH
Michi
At least we could have
> watched it grow, and he would have not been "slowed" with "community" as
> he now likes to say ;-) In any case, he's free to do so if he wishes,
> and we will see what to do when this thing will land here.
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> On 28 Nov 2003, at 03:46, David Crossley wrote:
...
>> Mmmm, i am not sure that i like this approach. "Doco" sounds
>> to me like one of the reasons that "Forrest" was started.
>
> that's right, but forrest took a different path and now focuses on
> static generation of web sites, full blown content management is not at
> reach there anymore.
Although we have currently decided to focus on the final generation step
(not only CLI, but still the last presentation step), of course it does
not mean that Doco could not be a part of Forrest.
I mean *could* not *should*.
ATM Doco is so virtual that I cannot say anything about it.
>> What is worrying is that this one-person thing (though i trust
>> Stefano to know what to do) will have no community to land in
>> and Apache will spawn yet another new project.
Well, Doco ahould be a glue that it to put together different projects
in a coherent vision. We have Slide (backend), Lenya (CMS), Forrest
(presentation).
Look at the Forrest community now. Do you think we are ready and willing
to lead such a design? Speaking for me, not now, I still have lots of
work to do on what Forrest does now.
To be honest, Stefano has already told us about it and already got
feedback from all these projects, so in fact he is already working with
our ACK. Furthermore, there is no decision yet about where to place it,
or even if it will ever be something autonomous.
What I don't really understand is that he is not using a public Apache
repository, like the Cocoon scratchpad, to do it. At least we could have
watched it grow, and he would have not been "slowed" with "community" as
he now likes to say ;-) In any case, he's free to do so if he wishes,
and we will see what to do when this thing will land here.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 03:27, David Crossley wrote:
> Stefano Mazzocchi wrote:
>> David Crossley wrote:
>>
>>> Mmmm, i am not sure that i like this approach. "Doco" sounds
>>> to me like one of the reasons that "Forrest" was started.
>>
>> that's right, but forrest took a different path and now focuses
>> on static generation of web sites, full blown content management
>> is not at reach there anymore.
>
> That is a rash statement from afar.
>
> Forrest was started by some visionaries with grand plans.
> After a very short while, most of those people disappeared
> and only a few committers remained to assist the fledgling.
>
> Forrest documentation still talked about the grander plans.
> Brilliant though it is, Forrest had to pull its horns in,
> as it was not yet delivering on that vision.
>
> So certain dreams had to be "shelved". Not abandoned, just put on
> hold until there were participants, and real use cases to meet.
>
> There were also recent cases where some new committers started to
> set up some default facilities which assumed a servlet environment
> and thereby broke the static docs build. We decided that the
> primary focus be static, yet enable project-specific dynamic.
one of the main goals of doco is to have 'zero codebase'... it's only a
plan, a vision, an architecture and a lot of configuration file. There
will be no *technical* overlap with the projects, doco is just a
project to "eat our dog food", shelving certain dreams in order to make
them come true.
It is true that forrest was started with that idea in mind, but later
turned out that people wanted to use it for their own stuff and it was
hard to keep goals in synch since a common denominator was needed.
instead of fighting to lock forrest down, I decided to step out and let
it grow.
Now, I'm back on the original dream that started in 1998: writing a
document management system (some people called it a "distributed word
processor") for our projects and use it as a testbase for further
research on the semantic web.
This *does not* overlap with any other project out there: no project is
focused on a single implementation and installation, but they are
focusing on writing reusable software.
SoC: Doco uses and glues pieces, the projects build the pieces and
receive back from Doco what they can incorporate in the general pieces.
This is my goal, but of course, I'm wide open to suggestions on how to
make things easier for everybody.
--
Stefano.
Re: Doco needs landing
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> David Crossley wrote:
>
> > Mmmm, i am not sure that i like this approach. "Doco" sounds
> > to me like one of the reasons that "Forrest" was started.
>
> that's right, but forrest took a different path and now focuses
> on static generation of web sites, full blown content management
> is not at reach there anymore.
That is a rash statement from afar.
Forrest was started by some visionaries with grand plans.
After a very short while, most of those people disappeared
and only a few committers remained to assist the fledgling.
Forrest documentation still talked about the grander plans.
Brilliant though it is, Forrest had to pull its horns in,
as it was not yet delivering on that vision.
So certain dreams had to be "shelved". Not abandoned, just put on
hold until there were participants, and real use cases to meet.
There were also recent cases where some new committers started to
set up some default facilities which assumed a servlet environment
and thereby broke the static docs build. We decided that the
primary focus be static, yet enable project-specific dynamic.
--David
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 28 Nov 2003, at 03:46, David Crossley wrote:
> Stefano Mazzocchi wrote:
>> Reinhard Poetz wrote:
>>
>>> ok, is there a way for others to help you or in other words:
>>> do you need some help?
>>
>> No, I move faster if I do stuff myself. There is no much code to
>> write,
>> just a lot of glue and finding out the pieces of the puzzle and
>> working
>> with somebody else is going to slow this down in prototypical phase.
>>
>> After the prototype is ready, there will be *tons* of polishing to do,
>> but I want to create the itches first, so that all of us can scratch
>> later.
>
> Mmmm, i am not sure that i like this approach. "Doco" sounds
> to me like one of the reasons that "Forrest" was started.
that's right, but forrest took a different path and now focuses on
static generation of web sites, full blown content management is not at
reach there anymore.
> What is worrying is that this one-person thing (though i trust
> Stefano to know what to do) will have no community to land in
> and Apache will spawn yet another new project.
> I don't mean to be cynical or anything, but Linotype and Portal
> landed in Cocoon as more-or-less functional things and not much
> has happened since.
wait a full second, David. I can't talk for Portal-oriented stuff since
I don't use it, but for linotype, it was ported to be IE5/mozilla
cross-platform, I received a few patches and Joerg is patching it to
fix jetty problems and there were discussions about integration with
cocoon forms and Lenya.
might not be "much", but it's something promising.
> I know that there is a trade-off between too much talk and not
> enough doing. However, without any discussion there is a risk
> that something fundamental will be missed.
I already did a full blown discussion on Doco. Everybody expressed a
warm +1 as several projects are involved: cocoon, forrest, lenya, james
and slide. Nobody complained about duplication of effort, rather the
opposite: everybody was happy to be used exactly for what it was
designed to do.
What to know what I'm doing right now? I'm debugging mount_webdav in
Darwin because there is a bug in their handling of webdav locks and I
can't mount a slide repository under mach-o. Yes, C code and recompile
part of my OS kernel, that's how bleeding-edge I'm getting.
If you think there is something wrong in the proposal, resurrect it and
complain. I'm all ears.
I told you I'm sick of politics and want to do stuff. I'm doing it. It
will be simply a proposal: it's easier to work alone that to make 5
different projects coordinating. If you disagree, you are more than
welcome to continue it the "community way". We'll see who comes out
with something that works faster.
After my proposal lands, you are welcome to tear it apart entirely. The
design is public, as the discussions that lead to it. If you have
technical suggestions, let's hear them. If you have community building
suggestions, well, I'll be happy to listen to them after the damn thing
will be saying "hello world".
In the meanwhile, as I said, don't wait for me.
--
Stefano.