cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: cvs commit: xml-cocoon2/src/org/apache/cocoon Main.java
Date Wed, 17 Oct 2001 11:06:29 GMT
> Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> >
> > > Berin Loritsch wrote:
> > >
> > > cziegeler@apache.org wrote:
> > > >
> > > > cziegeler    01/10/16 06:04:57
> > > >
> > > >   Modified:    src/org/apache/cocoon Main.java
> > > >   Log:
> > > >   Added checking for duplicate urls
> > >
> > > So why the change from Set to List?  If you have to do all this extra
> > > stuff, the code becomes less readable and maintainable.  The
> performance
> > > gain can't be that great.
> > >
> > No, it has nothing to do with performance. And yes, it is less readable,
> > but it is natural that if you specify more than one url using
> e.g. a file,
> > that these urls are processed exactly in the order they were specified
> > and not in any arbitrary order. And thats exactly why a List is better
> > than a Set.
>
> I see.  I wasn't aware that site generation had to be done in any
> particular
> order.  If the result at the end of the generation is the same whether you
> use a Set or a List, I don't see the advantage.  (I am playing
> devil's advocate).
>
> If you run into errors due to the order of processing, I could
> understand--
> then again I would want to know why there was an order enforced
> in the beginning.
> Basically all we are doing is treating the CLI version like the
> Servlet version.
> Requests can come in any order.
Sorry, I don't agree here. If you have one client (one user with
his browser), then the requests from this client come in ordered
as the user starts on the welcome page, needs authentication and
then goes where he wants.
No I compare the cli with exactly one client, there is no other
"client" involved when the cli is run.

>
> My only point is this, a lot of work went into a minor change
> that could have
> been spent on some of our more major issues.  I wouldn't back out
> the change
> now, though.
Hmmm, you got me!

Carsten
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message