You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/10/29 22:46:36 UTC
Back from Germany
All right, I'm back from Germany.
Last week I tried to make it for the Frankfurt gettogether but I had a
car crash and I couldn't make it. :/ Luckily nobody got hurt, I just
couldn't drive any longer and I had to come back home.
So I took the plain to Bonn where I spoke at the http://netzspannung.org
workshop
http://netzspannung.org/workshops/online-archives/program/#Panel_3
The speech was 'The Economy of Distributed Metadata Authoring' and was,
in short, a critic to the semantic web technologies from a
socio-economical point of view.
I managed to get a vew people depressed (sort of: what are we going to
do now?) but I got very positive feedback, expecially from the oldest
people (wisest?). Ah, you can see the webcast if you're really
interested (there were some neat stuff in my panel, very interesting
projects, expecially with the use of heuristically extracted MPEG-7
metadata from video streams. Cool stuff.)
Anyway, after that, I took the train up to Paderborn to visit Carsten
and Matthew. (first thing I learned: german trains are not so 'on-time'
like the stereotype suggest. second: they are *very* expensive!)
Anyway, I reached Paderborn during a pretty heavy storm (as usual!) and
we went visiting the 'computer museum' at the old Nixdorf offices.
We had a great time there :) And it was soo cool to see a Commodore
Vic-20 exposed in a museum since I stil have mine functioning at home :)
But the downside is that I felt kinda old, you know :) Gee, 21 years of
programming experience and 28 years-old. I think I should get a life one
day :)
Anyway, I won't go over everything that happened there, but the
important thing for us is that I finally managed to explain the block
concept to Carsten the way I intended it.
And he loved it :)
We agreed not to start implementing it until 2.1 is out but we outlines
the system so that it minimizes the impacts on both the current
architecture and, more important, on the usability of Cocoon in general.
The idea is to give the users the ability to move to blocks in a very
easy and natural way. That is:
phase 1) use Cocoon as you do today. You won't be forced to use blocks
if you don't need them or you don't understand them.
phase 2) use blocks just for deployment. This is mostly similar at WAR
files today: just package your stuff as a block and deploy it on a
running Cocoon.
phase 3) use blocks for deployment and depend on other blocks. This
will work sort-of APT-get: when you deploy your block and you need, for
example, FOP, Cocoon will deploy your stuff and then go looking for the
FOP block and deploy it for you. Of course, the behavior will be all
user-selectable and all that but that's the general idea
phase 4) users will start providing their own blocks to others to
depend on.
Also, we planned on having a web interface on top of Cocoon for
configurations and for block deployment. Of course, all secured and
possibly to be turned off for production environments.
NOTE: the current block-like refactorization for Cocoon 2.1 is actually
a great thing because it already removes stuff from the 'main cocoon'
and cleans up the things that we'll later move on real and dynamically
deployable cocoon blocks. So, there is no need to rush or to change what
is being going on today.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Back from Germany
Posted by Vadim Gritsenko <va...@verizon.net>.
Leo Sutic wrote:
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>
>> phase 2) use blocks just for deployment. This is mostly
>>similar at WAR
>>files today: just package your stuff as a block and deploy it on a
>>running Cocoon.
>>
>>
>
>Stefano,
>
>does this imply that Cocoon will move from being a servlet
>
No, it doesn't. Cocoon still will operate as Servlet or command line
utility.
> to
>becoming an integral part of the servlet container?
>
However, if you are interested in this and know how to do it, you can do
it right know, by writing another "startup" class for Cocoon (in
addition to Main and CocoonServlet), and may be another environment.
Vadim
>/LS
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Using the Wiki for concepts and design (was: Back from Germany)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 31 October 2002 14:30, Carsten Ziegeler wrote:
>. . .But sometimes it's very hard to make
> complex concepts clear by simply exchanging emails.
>. . .
Here are my 2 cents ;-)
IMHO that's where a wiki can help a lot: collaborating on writing and
refining use-cases or specs (few documents, many tracable authors, instant
summary) instead of "talking" about them by email (many documents, hard to
summarize). A wiki has a lot in common with a whiteboard or wall of paper
which is known to be one of the best ways of collaborating on designs.
There is some content about blocks at
http://outerthought.net/wiki/Wiki.jsp?page=Blocks, might be out of sync with
the current concept but I think it shows how powerful 2-3 wiki pages can be
in summarizing/refining concepts.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Back from Germany
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
>
> I've been calling this way of doing software "open development" since
> "open source" refers to the distribution of software, not the way the
> development community is run.
>
> I don't want anybody (so myself included) to do anything behind the back
> of anybody. Nor to make it appear that when (unfortunately rarely)
> people get together in real life to talk, this appears as doing hidden
> things or secret plans.
>
I must confess that perhaps my email, telling that I discussed blocks
with Stefano, had exactly the message that we two are doing something
behind the back of the community. But believe me, this is not the case!
I totally agree with Stefano that "open development" is the way to go,
otherwise sooner or later we would create friction in the community.
Concerning blocks, the only thing happened was that we discussed the
proposal by Stefano which I didn't understand back then. We also
discussed some parts which were not covered yet in the proposal.
But discussing these things should and will only result in new
proposals which will be presented. So all can take part in discussing,
designing and implementing. But sometimes it's very hard to make
complex concepts clear by simply exchanging emails.
> The perception of openness is not only important, is the *key* to a
> healhty stable and diverse community.
>
> > I like it.
> > It is something I've seen as the logical conclusion for quite some
> > time. Imagine - instead of deploying a war to deploy car (cocoon
> > archives) and so on, cocoon webapps are raised to the same level
> > as normal webapps.
> >
> > 2) I haven't been following cocoon-dev much. Your previous discussion
> > was probably completely missed by me.
> >
>
> I'll do a sum-up soon.
>
Great and thanks!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Back from Germany
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
> Stefano,
>
> 1) I don't care if you do it behind my back or wherever.
You might not, but I do.
I've been calling this way of doing software "open development" since
"open source" refers to the distribution of software, not the way the
development community is run.
I don't want anybody (so myself included) to do anything behind the back
of anybody. Nor to make it appear that when (unfortunately rarely)
people get together in real life to talk, this appears as doing hidden
things or secret plans.
The perception of openness is not only important, is the *key* to a
healhty stable and diverse community.
> I like it.
> It is something I've seen as the logical conclusion for quite some
> time. Imagine - instead of deploying a war to deploy car (cocoon
> archives) and so on, cocoon webapps are raised to the same level
> as normal webapps.
>
> 2) I haven't been following cocoon-dev much. Your previous discussion
> was probably completely missed by me.
>
I'll do a sum-up soon.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Back from Germany
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Leo Sutic wrote:
>
> >
> > >From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > >
> > > phase 2) use blocks just for deployment. This is mostly
> similar at
> > >WAR files today: just package your stuff as a block and
> deploy it on
> > >a running Cocoon.
> >
> >
> > Stefano,
> >
> > does this imply that Cocoon will move from being a servlet
> to becoming
> > an integral part of the servlet container?
>
> Hey, people, I wrote several thousands of lines of emails
> about the subject.
>
> I'm not doing this behind your back, it's all here on cocoon-dev
> already, just search for 'cocoon block' or 'cob' on the mail archives.
>
> I'm restating all this because Carsten didn't got the point
> and Giacomo
> and I could have the idea across.
>
> But from your comments it seems that it's still that case.
Stefano,
1) I don't care if you do it behind my back or wherever. I like it.
It is something I've seen as the logical conclusion for quite some
time. Imagine - instead of deploying a war to deploy car (cocoon
archives) and so on, cocoon webapps are raised to the same level
as normal webapps.
2) I haven't been following cocoon-dev much. Your previous discussion
was probably completely missed by me.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Back from Germany
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
> >From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > phase 2) use blocks just for deployment. This is mostly
> >similar at WAR
> >files today: just package your stuff as a block and deploy it on a
> >running Cocoon.
>
>
> Stefano,
>
> does this imply that Cocoon will move from being a servlet to
> becoming an integral part of the servlet container?
Hey, people, I wrote several thousands of lines of emails about the subject.
I'm not doing this behind your back, it's all here on cocoon-dev
already, just search for 'cocoon block' or 'cob' on the mail archives.
I'm restating all this because Carsten didn't got the point and Giacomo
and I could have the idea across.
But from your comments it seems that it's still that case.
All right, I'll try to come up with a more detailed proposal soon and
restart the whole design discussion, hopefully with more input from people.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Back from Germany
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> phase 2) use blocks just for deployment. This is mostly
> similar at WAR
> files today: just package your stuff as a block and deploy it on a
> running Cocoon.
Stefano,
does this imply that Cocoon will move from being a servlet to
becoming an integral part of the servlet container?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Back from Germany
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> All right, I'm back from Germany.
>
I hope you had a nice and easy trip back without any storm!
>
> Anyway, I won't go over everything that happened there, but the
> important thing for us is that I finally managed to explain the block
> concept to Carsten the way I intended it.
>
> And he loved it :)
>
Oh, you know - I had to directly confrontated with you in person :)
No, just kidding - I really can value it now. I misunderstood the
concept in the first time and now after realizing it, I can't wait
that you start implementing it ;)
> We agreed not to start implementing it until 2.1 is out but we outlines
> the system so that it minimizes the impacts on both the current
> architecture and, more important, on the usability of Cocoon in general.
>
> The idea is to give the users the ability to move to blocks in a very
> easy and natural way. That is:
>
> phase 1) use Cocoon as you do today. You won't be forced to use blocks
> if you don't need them or you don't understand them.
>
> phase 2) use blocks just for deployment. This is mostly similar at WAR
> files today: just package your stuff as a block and deploy it on a
> running Cocoon.
>
> phase 3) use blocks for deployment and depend on other blocks. This
> will work sort-of APT-get: when you deploy your block and you need, for
> example, FOP, Cocoon will deploy your stuff and then go looking for the
> FOP block and deploy it for you. Of course, the behavior will be all
> user-selectable and all that but that's the general idea
>
> phase 4) users will start providing their own blocks to others to
> depend on.
>
> Also, we planned on having a web interface on top of Cocoon for
> configurations and for block deployment. Of course, all secured and
> possibly to be turned off for production environments.
>
And this is the part where we spend most time, because this is the interface
to the Cocoon user. This has to be very clear and simple but of course
powerfull.
And the great thing is, that this web interface will be developed using
Cocoon and it's components. So it is also a good presentation of Cocoon
itself: we can show flow script, svg generation etc.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org