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 Thu, 12 Jul 2001 06:04:07 GMT
> Vadim Gritsenko wrote:
>
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > Sent: Wednesday, July 11, 2001 9:33
> > To: cocoon-dev@xml.apache.org
> > Subject: AW: [C2]: Planning beta 2
> >
> >
> > >  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.
>
> That is fine, if you are sure that timestamp would be enough to
> make a decision
> about content's validity.
>
Hi Vadim,

I thought yesterday, that it was me who broke the caching of CA,
so it should be myself who must fix this. And here is the good news:
Actually, I made the CA cacheable last night and will check it in today.
For this I didn't have to change any interface. The cocoon urls
(or the SitemapSource) calculates now a last modification date for the
source and this is used. This makes even the file generator etc.
cacheable if the source is a cocoon url.

>
> > > 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
>
> I know.
>
> > 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.
>
> Is it a contract between Source and component which is uses it
> that refresh()
> _must_ always be called? Then this solves this issue.
>
Yes, it is a contract between them. The component can use the Source
object only once. After that it must call refresh() to use it again.

I hope I can come up with a documentation on url and source handling next
week.

>
> > > 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.
>
> You missed the point here. It is called once _per_component_.
> Let's assume that you have following sitemap:
> <aggregator>
>   <part>
>     <aggregator>
>       <part>
>         <generator>
>         <transformer>
>         <transformer>
>       </part>
>       <part>
>         <generator>
>         <transformer>
>         <transformer>
>       </part>
>     </aggregator>
>     <transformer>
>     <transformer>
>   </part>
>   <part>
>     <generator>
>     <transformer>
>     <transformer>
>   </part>
> </aggregator>
> <transformer>
> ...
>
> Every generator/transformer have HashUtul.hash() call, then
> resulting "long"s are combined into
> string and content aggregator calls HashUtul.hash() again, and so
> on (if you have more
> then one level of aggregation). And that's not even performance
> concern here, but the
> quality of the resulting key - could it be that it would degrade
> when you use more levels
> of content aggregation?
>
> That's why I'm thinking that it might be better to hash string
> only once, without
> recursion.
>
Ah, ok, you're right. I think, as the working solution makes no
difference between CA and the normal file generator and no
difference between a cocoon url and a http url, we can leave
everything at it is right now.
The overhead is as minimal as possible without changing interfaces.

Carsten

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


Mime
View raw message