You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2002/03/08 16:09:11 UTC
Release early? (was: Roadmap Executive Plan)
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
<snip/>
> Finally, when are we doing 2.0.2?
Does somebody remember what is "release early, release often" means? I
must confess I forgot the meaning of this...
> What are we waiting for?
I guess we are waiting when Carsten gets well ;)
Disclaimer: This mail supposed to be provocative... That's my first try,
don't mail-bomb me please :)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release early? (was: Roadmap Executive Plan)
Posted by Matthew Langham <ml...@s-und-n.de>.
>>
> What are we waiting for?
I guess we are waiting when Carsten gets well ;)
<<
Wow....please.....it will get to his head :-).
Carsten will be back in "limited" action from Monday.
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
-----Original Message-----
From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
Sent: Friday, March 08, 2002 4:09 PM
To: cocoon-dev@xml.apache.org; 'Nicola Ken Barozzi'
Subject: Release early? (was: Roadmap Executive Plan)
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
<snip/>
> Finally, when are we doing 2.0.2?
Does somebody remember what is "release early, release often" means? I
must confess I forgot the meaning of this...
> What are we waiting for?
I guess we are waiting when Carsten gets well ;)
Disclaimer: This mail supposed to be provocative... That's my first try,
don't mail-bomb me please :)
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: Release early? (was: Roadmap Executive Plan)
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> Quoting Carsten Ziegeler <cz...@s-und-n.de>:
>
> > > Sylvain Wallez wrote:
> > > <snip>
> > > >
> > > >>A question about sunRise : is it possible to use standard HTTP
> > > >>authentication and authorization ? AFAICS, it seems to be very tied
> > to
> > > >>form-based and application-managed authentication.
> > > >>
> > > >
> > > >You can use any information you can reach from within the Java code.
> > > >I'm not sure if there is a change to get the HTTP authentication
> > infos.
> > > >If yes, you can use sunRise.
> > > >
> > > The problem comes from the login page. With HTTP authentication, you
> > > don't have a dedicated login page, and thus cannot use this one to
> > > handle authentication. Or did I miss something ?
> > >
> >
> > Hm, correct me if I'm wrong as we never used HTTP authentication with
> > sunRise.
> > If a user requests a URI from the web server which is protected, the web
> > server
> > (or the browser) prompts for the authentication information.
>
> Yes. This is true for all kinds of authentication types (BASIC-AUTH as
well as
> SSL client certs).
>
> > Only if the
> > user is authenticated this request is forwarded to the servlet engine.
> ^ by the web server
And the web server can be the same as the servlet engine.
>
> > Is this correct?
>
> Yes.
>
> > If this is so, the servlet engine can - without using a form - use the
> > sunRise-login
> > action, get the information from the web server (if possible) and log
> > the
> > user
> > into sunRise.
>
> Yes, without redirecting it to a login page (in any case). In the case the
> Action thinks a user is not authorized it has to tell it back to the web
server
> by using the corresponding HTTP response code (5xx IIRC).
SC_UNAUTHORIZED
public static final int SC_UNAUTHORIZED
Status code (401) indicating that the request requires HTTP authentication.
Regards,
Konstantin
>
> The authenticating server and the application share a common user base
(the web
> server for authentication and the application for authorisation).
>
> > Does this make sense?
>
> I think so.
>
> Giacomo
>
> ---------------------------------------------------------------------
> 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: Release early? (was: Roadmap Executive Plan)
Posted by gi...@apache.org.
Quoting Carsten Ziegeler <cz...@s-und-n.de>:
> > Sylvain Wallez wrote:
> > <snip>
> > >
> > >>A question about sunRise : is it possible to use standard HTTP
> > >>authentication and authorization ? AFAICS, it seems to be very tied
> to
> > >>form-based and application-managed authentication.
> > >>
> > >
> > >You can use any information you can reach from within the Java code.
> > >I'm not sure if there is a change to get the HTTP authentication
> infos.
> > >If yes, you can use sunRise.
> > >
> > The problem comes from the login page. With HTTP authentication, you
> > don't have a dedicated login page, and thus cannot use this one to
> > handle authentication. Or did I miss something ?
> >
>
> Hm, correct me if I'm wrong as we never used HTTP authentication with
> sunRise.
> If a user requests a URI from the web server which is protected, the web
> server
> (or the browser) prompts for the authentication information.
Yes. This is true for all kinds of authentication types (BASIC-AUTH as well as
SSL client certs).
> Only if the
> user is authenticated this request is forwarded to the servlet engine.
^ by the web server
> Is this correct?
Yes.
> If this is so, the servlet engine can - without using a form - use the
> sunRise-login
> action, get the information from the web server (if possible) and log
> the
> user
> into sunRise.
Yes, without redirecting it to a login page (in any case). In the case the
Action thinks a user is not authorized it has to tell it back to the web server
by using the corresponding HTTP response code (5xx IIRC).
The authenticating server and the application share a common user base (the web
server for authentication and the application for authorisation).
> Does this make sense?
I think so.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Sylvain Wallez wrote:
> <snip>
> >
> >>A question about sunRise : is it possible to use standard HTTP
> >>authentication and authorization ? AFAICS, it seems to be very tied to
> >>form-based and application-managed authentication.
> >>
> >
> >You can use any information you can reach from within the Java code.
> >I'm not sure if there is a change to get the HTTP authentication infos.
> >If yes, you can use sunRise.
> >
> The problem comes from the login page. With HTTP authentication, you
> don't have a dedicated login page, and thus cannot use this one to
> handle authentication. Or did I miss something ?
>
Hm, correct me if I'm wrong as we never used HTTP authentication with
sunRise.
If a user requests a URI from the web server which is protected, the web
server
(or the browser) prompts for the authentication information. Only if the
user is authenticated this request is forwarded to the servlet engine.
Is this correct?
If this is so, the servlet engine can - without using a form - use the
sunRise-login
action, get the information from the web server (if possible) and log the
user
into sunRise.
Does this make sense?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release early? (was: Roadmap Executive Plan)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>>Carsten Ziegeler wrote:
>><snip>
>>
>>>a) Sitemap components in the cocoon.xconf.
>>>Now, personally I don't like this - but that's my own opinion about this.
>>>If you want to edit the sitemap, you not only have to look at the sitemap
>>>but also at the cocoon.xconf. This makes handling the sitemap even more
>>>complicated.
>>>I know a lot of people complaining about the complexity of Cocoon and
>>>the many places of configuration. By this splitting of component
>>>definition it gets even harder for beginners.
>>>
>>>So I would like to have all these definitions back in the sitemap.
>>>What is the benefit of having them in the cocoon.xconf?
>>>
>>The benefit is reduced length of the <map:components> section in the
>>sitemap, which is both tedious to copy/paste in every sitemap and really
>>frightening for some beginners, and provide some sitemap components to
>>other components that could use them (thinking mainly about the xml
>>serializer).
>>
>
>What do you mean by copy/paste in every sitemap? I assume you don't mean
>sub-sitemaps as they inherit the components from the main sitemap, right?
>
No, of course no :) I was talking about the root sitemap of each
application.
>Hm, other components can use the sitemap components if they are instantiated
>from within a sitemap component.
>
Yes, but some are created outside of this scope. These are for example
SourceFactories, which may need a serializer.
>>About frightened users, what about reversing the order of sections in
>>the sitemap : start with pipelines, which describe the contract with the
>>external world, then resources, view, actions and lastly components ?
>>
>
>Sounds not so bad.
>
Cool.
>>>b) the sunRise and sunSpot components
>>>What is the feeling of the community to move them out of the scratchpad
>>>into the main trunk? I'm - of course :) - +1 on moving them.
>>>
>>Before moving sun* to the main trunk, we should discuss how it could be
>>better integrated into Cocoon. For now, it's in Cocoon's CVS (thanks
>>again for this donation), but is built 'on top' of it, while some of its
>>components are of general purpose and could be moved in existing Cocoon
>>packages where they could gain more exposure and thus a wider use.
>>
>
>Yes, good idea!
>
>>A question about sunRise : is it possible to use standard HTTP
>>authentication and authorization ? AFAICS, it seems to be very tied to
>>form-based and application-managed authentication.
>>
>
>You can use any information you can reach from within the Java code.
>I'm not sure if there is a change to get the HTTP authentication infos.
>If yes, you can use sunRise.
>
The problem comes from the login page. With HTTP authentication, you
don't have a dedicated login page, and thus cannot use this one to
handle authentication. Or did I miss something ?
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: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
> <snip>
> >
> >a) Sitemap components in the cocoon.xconf.
> >Now, personally I don't like this - but that's my own opinion about this.
> >If you want to edit the sitemap, you not only have to look at the sitemap
> >but also at the cocoon.xconf. This makes handling the sitemap even more
> >complicated.
> >I know a lot of people complaining about the complexity of Cocoon and
> >the many places of configuration. By this splitting of component
> definition
> >it gets even harder for beginners.
> >So I would like to have all these definitions back in the sitemap.
> >What is the benefit of having them in the cocoon.xconf?
> >
> The benefit is reduced length of the <map:components> section in the
> sitemap, which is both tedious to copy/paste in every sitemap and really
> frightening for some beginners, and provide some sitemap components to
> other components that could use them (thinking mainly about the xml
> serializer).
>
What do you mean by copy/paste in every sitemap? I assume you don't mean
sub-sitemaps as they inherit the components from the main sitemap, right?
Hm, other components can use the sitemap components if they are instantiated
from within a sitemap component.
> About frightened users, what about reversing the order of sections in
> the sitemap : start with pipelines, which describe the contract with the
> external world, then resources, view, actions and lastly components ?
>
Sounds not so bad.
> >b) the sunRise and sunSpot components
> >What is the feeling of the community to move them out of the scratchpad
> >into the main trunk? I'm - of course :) - +1 on moving them.
> >
> Before moving sun* to the main trunk, we should discuss how it could be
> better integrated into Cocoon. For now, it's in Cocoon's CVS (thanks
> again for this donation), but is built 'on top' of it, while some of its
> components are of general purpose and could be moved in existing Cocoon
> packages where they could gain more exposure and thus a wider use.
>
Yes, good idea!
> A question about sunRise : is it possible to use standard HTTP
> authentication and authorization ? AFAICS, it seems to be very tied to
> form-based and application-managed authentication.
>
You can use any information you can reach from within the Java code.
I'm not sure if there is a change to get the HTTP authentication infos.
If yes, you can use sunRise.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release early? (was: Roadmap Executive Plan)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hmm, "release early" what does it mean?
>I think we should release a new version before lunch. Is that
>early enough?
>
>Ok, odd joke, let's get serious now:
>
>The problem with Cocoon and release early is the wast amount of
>changes that occur between versions. But I really would like
>to make a 2.0.2 asap.
>As I couldn't follow all the changes and discussions in the
>last two weeks, can someone summarize this please? Are the changes.xml
>up-to-date?
>
>I have at least two topics I would like to address:
>
>a) Sitemap components in the cocoon.xconf.
>Now, personally I don't like this - but that's my own opinion about this.
>If you want to edit the sitemap, you not only have to look at the sitemap
>but also at the cocoon.xconf. This makes handling the sitemap even more
>complicated.
>I know a lot of people complaining about the complexity of Cocoon and
>the many places of configuration. By this splitting of component definition
>it gets even harder for beginners.
>So I would like to have all these definitions back in the sitemap.
>What is the benefit of having them in the cocoon.xconf?
>
The benefit is reduced length of the <map:components> section in the
sitemap, which is both tedious to copy/paste in every sitemap and really
frightening for some beginners, and provide some sitemap components to
other components that could use them (thinking mainly about the xml
serializer).
About frightened users, what about reversing the order of sections in
the sitemap : start with pipelines, which describe the contract with the
external world, then resources, view, actions and lastly components ?
>b) the sunRise and sunSpot components
>What is the feeling of the community to move them out of the scratchpad
>into the main trunk? I'm - of course :) - +1 on moving them.
>
Before moving sun* to the main trunk, we should discuss how it could be
better integrated into Cocoon. For now, it's in Cocoon's CVS (thanks
again for this donation), but is built 'on top' of it, while some of its
components are of general purpose and could be moved in existing Cocoon
packages where they could gain more exposure and thus a wider use.
A question about sunRise : is it possible to use standard HTTP
authentication and authorization ? AFAICS, it seems to be very tied to
form-based and application-managed authentication.
<snip/>
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: Release early? (was: Roadmap Executive Plan)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Carsten Ziegeler" <cz...@s-und-n.de>
> > Carsten Ziegeler wrote:
> > a) Sitemap components in the cocoon.xconf.
> > Now, personally I don't like this - but that's my own opinion about
this.
> > If you want to edit the sitemap, you not only have to look at the
sitemap
> > but also at the cocoon.xconf. This makes handling the sitemap even more
> > complicated.
> > I know a lot of people complaining about the complexity of Cocoon and
> > the many places of configuration. By this splitting of component
> > definition
> > it gets even harder for beginners.
> > So I would like to have all these definitions back in the sitemap.
> > What is the benefit of having them in the cocoon.xconf?
How I see it, the components should be configured out of the sitemap, but
cocoon.xconf is not the best solution for this.
AFAIK, there was a discussion on the configuration files going on, and on
Cocoon Blocks.
I'd put also this point:
d) restructure samples using subsitemaps.
I'm halfway through, and with the new dir layout, it makes more sense to
have basic Sitemap Cocmponents included in xconf.
> > b) the sunRise and sunSpot components
> > What is the feeling of the community to move them out of the scratchpad
> > into the main trunk? I'm - of course :) - +1 on moving them.
Hmmm... I'm not so sure. I love what they do, don't get me wrong, but I
would prefer to have them integrated in the *whole* Cocoon samples instead
of being just part of it.
>
> c) Rename the CVS repository as by Stefano's suggestion:
> Rename xml-cocoon to xml-cocoon1 and xml-cocoon2 to xml-cocoon
> to keep the history.
+0
--
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: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I added a third point, see below:
> Carsten Ziegeler wrote:
>
> Hmm, "release early" what does it mean?
> I think we should release a new version before lunch. Is that
> early enough?
>
> Ok, odd joke, let's get serious now:
>
> The problem with Cocoon and release early is the wast amount of
> changes that occur between versions. But I really would like
> to make a 2.0.2 asap.
> As I couldn't follow all the changes and discussions in the
> last two weeks, can someone summarize this please? Are the changes.xml
> up-to-date?
>
> I have at least two topics I would like to address:
>
> a) Sitemap components in the cocoon.xconf.
> Now, personally I don't like this - but that's my own opinion about this.
> If you want to edit the sitemap, you not only have to look at the sitemap
> but also at the cocoon.xconf. This makes handling the sitemap even more
> complicated.
> I know a lot of people complaining about the complexity of Cocoon and
> the many places of configuration. By this splitting of component
> definition
> it gets even harder for beginners.
> So I would like to have all these definitions back in the sitemap.
> What is the benefit of having them in the cocoon.xconf?
>
> b) the sunRise and sunSpot components
> What is the feeling of the community to move them out of the scratchpad
> into the main trunk? I'm - of course :) - +1 on moving them.
>
c) Rename the CVS repository as by Stefano's suggestion:
Rename xml-cocoon to xml-cocoon1 and xml-cocoon2 to xml-cocoon
to keep the history.
> Cheers,
> Carsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release early? (was: Roadmap Executive Plan)
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Monday, March 11, 2002, at 09:40 am, Carsten Ziegeler wrote:
> a) Sitemap components in the cocoon.xconf.
> Now, personally I don't like this - but that's my own opinion about
> this.
> If you want to edit the sitemap, you not only have to look at the
> sitemap
> but also at the cocoon.xconf. This makes handling the sitemap even more
> complicated.
> I know a lot of people complaining about the complexity of Cocoon and
> the many places of configuration. By this splitting of component
> definition
> it gets even harder for beginners.
> So I would like to have all these definitions back in the sitemap.
> What is the benefit of having them in the cocoon.xconf?
We have a growing number of sites under development that use a common
configuration. Being able to put all the general cocoon configuration
in the cocoon.xconf file (configuration that requires knowledge of Java
class names and is quite often impacted by updates to cocoon and its
components), and keep site specific stuff in one or more "sitemap.xmap"
files is definitely beneficial.
Otherwise, every time Cocoon is updated we have to compare the diffs of
the supplied sitemap with the previous supplied version and implement
these in all our sitemaps. If, on the other hand, all of this is in
cocoon.xconf, we may be able to just get away with using the supplied
file (but for database configuration).
If we want to reduce complexity I would be in favour of deprecating the
facility for declaring components within sitemap.xmap.
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hmm, "release early" what does it mean?
I think we should release a new version before lunch. Is that
early enough?
Ok, odd joke, let's get serious now:
The problem with Cocoon and release early is the wast amount of
changes that occur between versions. But I really would like
to make a 2.0.2 asap.
As I couldn't follow all the changes and discussions in the
last two weeks, can someone summarize this please? Are the changes.xml
up-to-date?
I have at least two topics I would like to address:
a) Sitemap components in the cocoon.xconf.
Now, personally I don't like this - but that's my own opinion about this.
If you want to edit the sitemap, you not only have to look at the sitemap
but also at the cocoon.xconf. This makes handling the sitemap even more
complicated.
I know a lot of people complaining about the complexity of Cocoon and
the many places of configuration. By this splitting of component definition
it gets even harder for beginners.
So I would like to have all these definitions back in the sitemap.
What is the benefit of having them in the cocoon.xconf?
b) the sunRise and sunSpot components
What is the feeling of the community to move them out of the scratchpad
into the main trunk? I'm - of course :) - +1 on moving them.
Cheers,
Carsten
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: Friday, March 08, 2002 4:09 PM
> To: cocoon-dev@xml.apache.org; 'Nicola Ken Barozzi'
> Subject: Release early? (was: Roadmap Executive Plan)
>
>
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> <snip/>
>
> > Finally, when are we doing 2.0.2?
>
> Does somebody remember what is "release early, release often" means? I
> must confess I forgot the meaning of this...
>
>
> > What are we waiting for?
>
> I guess we are waiting when Carsten gets well ;)
>
>
> Disclaimer: This mail supposed to be provocative... That's my first try,
> don't mail-bomb me please :)
>
> 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