> -----Original Message-----
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 11, 2001 9:33
> To: [EMAIL PROTECTED]
> Subject: AW: [C2]: Planning beta 2
>
>
> > Vadim Gritsenko wrote:
> >
> > > -----Original Message-----
> > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> > > 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.
> > 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.
> > 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.
> 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: [EMAIL PROTECTED]
> ================================================================
>
> >
> > 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: [EMAIL PROTECTED]
> > > ================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
