cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: Planning beta 2
Date Wed, 11 Jul 2001 13:32:30 GMT
>  Vadim Gritsenko wrote:
> 
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > Sent: Tuesday, July 10, 2001 4:34
> > To: Cocoon-Dev@Xml. Apache. Org
> > Subject: [C2]: Planning beta 2
> > 
> > 
> > Hi Team,
> > 
> > I think it is time to plan our next release: beta 2.
> > Our plans were to make this release in the middle of july and
> > I think we can realize this.
> > 
> > Apart from more documentation which is of course important 
> > for the beta 2,
> > we have *only* to solve the bugs entered in bugzilla and
> > to finish outstanding issues. One of them is the content length
> > problem and the other is the class loading problem entered
> > in the todo list.
> > 
> > Is there any other thing to do?
> 
> Restore ContentAggregator's cachebility would be great...
> I did not have much time to spent on this, but have run into some 
> issues...
Yes, I agree here with you. The cachebility would really be great,
but currently my time is also limited. But perhaps we can work it
out until friday.
But however we should keep changes as small as possible. I still
believe that it is possible to make the CA cacheable without
changing any interfaces except the CachedEventObject which could
get a timestamp indicating when it was created.

> Can we add generateKey/validity methods to Source interface?
I think this is not a good design decision as the Source interface
only describes a resource. It doesn't know anything about caching.
And the decision about how the key (or the validity object) is build
can not be made by the Source object. Only the components using
a Source object can do this.

> And, because SitemapSource needs to construct pipeline which should be
> reused during generateKey/validity/stream (or 
> getTimestamp/stream) methods,
> it need to a recyclable component...
The Source object is not an avalon component, so we can't use the mimic
and as the Source object should be as lightweight as possible, I think
it is better this way. The Source object is itself "recycle" by calling
the "refresh" method.

> And connected to this issue... Should we call HashUtil.hash() 
> only once during
> key generation process for pipeline? Then it's better return 
> String as a key and
> then caller can hash it.
Sorry, again I don't agree here. During the pipeline processing the
generateKey method is called only once, so the hash function is
only called once. So I don't see any overhead here.
And there are components which can generate a key by not using
Strings, so it is more performant to use long as the return value
than to use Strings and hash them in these cases.


Carsten 

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de 
================================================================

> 
> Vadim
> 
> > 
> > If not, I would propose a code freeze for the end of the week
> > and a release date for the beta 2 could be 23rd of july.
> > 
> > What do you think?
> > 
> > Carsten 
> > 
> > Open Source Group                        sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de                          mailto: cziegeler@sundn.de 
> > ================================================================
> > 
> > 
> > ---------------------------------------------------------------------
> > 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
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message