You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/06/01 15:47:38 UTC
RE: Caching in cocoon, especially CIncludeTransformer
There is already such a component, the cinclude transformer uses this
for the caching. It should be easy to use that component in the
xinclude transformer as well.
PS: Could you please not include the PGP signature in your posts to
this list. It makes reading your mails very hard. Thanks.
Carsten
Torsten Knodt wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have looked at cocoon caching and it seems, that components do
> the caching
> for sources, DOM's and SAX events on their own. I wanted to make XInclude
> transformer cacheable, but this would only double code. Now I'm
> thinking of
> moving this somewhere to SourceUtil, XMLizers and SourceResolver. Someone
> already thought about this?
>
> Regards
> Torsten
> - --
> Domain in provider transition, hope for smoothness. Planed date
> is 1.7.2003.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE+2MXWvxZktkzSmiwRAnEJAJwMAGrcyM6YDCefxtsPBim7qMuerwCfW33S
> 0bCwChKYobY78YXDB4DJgHQ=
> =p+6b
> -----END PGP SIGNATURE-----
>
Re: Caching in cocoon, especially CIncludeTransformer
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>I don't know if this should be an independent component, or one that
>>extends the SourceResolver.
>>
>>
>Ah ok, by independent component I meant a component that extends
>perhaps the SourceResolver component from Avalon, but can still be
>looked up using a component manager. So that it is available in
>every component. This is in contrast to extending the Cocoon
>environment.SourceResolver interface that is only available in
>sitemap components.
>
>
Ah ok, I understand. Since Excalibur's SourceResolver than can be looked
up everywhere, I think we should strongly discourage the use of Cocoon's
legacy environment.SourceResolver, and consequently avoid enhancing it.
Having a new CocoonResolver extending Excalibur's SourceResolver seems
good to me.
But should this extended resolver be looked up with SourceResolver.ROLE,
or with a new CocoonResolver.ROLE ?
<random-thought>
This makes me think of a feature that would be good to have : component
aliasing.
Components that are not XML-related or that have no dependency on Cocoon
will lookup SourceResolver.ROLE, while Cocoon components that want to
use XML features will lookup CocoonResolver.ROLE.
Now, we will provide a single implementation for CocoonResolver and
hence (because of inheritance) SourceResolver. If two different roles
are used for the lookup, this normally means two different instances
(provided ths implementation iis ThreadSafe)
Now what if we were able to specify in cocoon.xconf that
SourceResolver.ROLE is just an alias for CocoonResolver.ROLE ? We would
have a single instance for two different roles.
The same could be used e.g. for InputOutputModules : we could have a
single e.g. SessionAttributeIOModule implementing both InputModule and
OutputModule, and have the 'session-attr' input-module configuration be
an alias for the 'session-attr' output-module.
</random-thought>
Sylvain (now awaken, stimulated by these wild thoughts ;-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Caching in cocoon, especially CIncludeTransformer
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> I don't know if this should be an independent component, or one that
> extends the SourceResolver.
Ah ok, by independent component I meant a component that extends
perhaps the SourceResolver component from Avalon, but can still be
looked up using a component manager. So that it is available in
every component. This is in contrast to extending the Cocoon
environment.SourceResolver interface that is only available in
sitemap components.
> But it would really be better to avoid too
> much code in static methods. And even more code that performs some
> component lookup under the scenes ;-)
Yepp
>
> Sylvain (having hard time to awake this morning ;-)
:)
Carsten
Re: Caching in cocoon, especially CIncludeTransformer
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>I don't like all those static methods that hardcode more and more logic,
>>and even less when they lookup some components...
>>
>>Why aren't these methods part of a CocoonResolver component that would
>>extend Excalibur's SourceResolver with some XML-related features ?
>>
>>
>>
>You mean an extra component and not the Cocoon SourceResolver, right?
>Ok, this could work and might be a cleaner solution. Agreed.
>
>
I don't know if this should be an independent component, or one that
extends the SourceResolver. But it would really be better to avoid too
much code in static methods. And even more code that performs some
component lookup under the scenes ;-)
Sylvain (having hard time to awake this morning ;-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Caching in cocoon, especially CIncludeTransformer
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> I don't like all those static methods that hardcode more and more logic,
> and even less when they lookup some components...
>
> Why aren't these methods part of a CocoonResolver component that would
> extend Excalibur's SourceResolver with some XML-related features ?
>
You mean an extra component and not the Cocoon SourceResolver, right?
Ok, this could work and might be a cleaner solution. Agreed.
Carsten
Re: Caching in cocoon, especially CIncludeTransformer
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Knodt wrote:
>On Sunday 01 June 2003 15:47, Carsten Ziegeler wrote:
>CZ> There is already such a component, the cinclude transformer uses this
>CZ> for the caching. It should be easy to use that component in the
>CZ> xinclude transformer as well.
>
Please, add a blank line before the reply, this will make reading easier.
>Yes, I know. But it'S still to much coding for it in the CIncludeTransformer. Components which need the content of a source, should simply get it, and not think about caching. It's not their job. Caching is needed in to many places. All places which use sources, should have caching. It should only be done at one place for each kind of data.
>
As Carsten, I don't agree with this : caching must be optional, and is
not useful in every place.
Take for example the XSLTProcessor : caching the source content from
which the stylesheet was read is useless, since we keep in the store the
corresponding pre-analyzed Templates object. The _validity_ of the
source is important to know if the stylesheet has changed, but caching
the stylesheet as DOM or SAX events is just waste of memory.
Another example are the "cocoon:" sources for which caching the source
is _always_ useless :
- either the called pipeline is cacheable in which case its contents is
stored in the Cocoon cache,
- either the called pipeline is not cacheable, and then caching the
source result is also useless, since this content will always be invalid.
>So what I suggest is introducing SourceUtil.getInputStream for InputStream's of sources. Then modify toDOM and toSAX to cache their output, to not have them to parse them first out of the cached InputStream's. So we would cache InputStream's, DOM's and SAX streams. The only changes in the components would be to use SourceUtil, where they currently use their own code.
>
>
I don't like all those static methods that hardcode more and more logic,
and even less when they lookup some components...
Why aren't these methods part of a CocoonResolver component that would
extend Excalibur's SourceResolver with some XML-related features ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Caching in cocoon, especially CIncludeTransformer
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Knodt wrote:
> Yes, I know. But it'S still to much coding for it in the
> CIncludeTransformer.
> Components which need the content of a source, should simply get
> it, and not
> think about caching. It's not their job. Caching is needed in to
> many places.
> All places which use sources, should have caching.
No, not *all* places. Caching is an option not a *must*. There are
sources that can be delivered faster without caching and there
are sources where you simply don't know if they update (when your
cache becomes invalid).
> It should only
> be done at
> one place for each kind of data.
> So what I suggest is introducing SourceUtil.getInputStream for
> InputStream's
> of sources. Then modify toDOM and toSAX to cache their output, to
> not have
> them to parse them first out of the cached InputStream's. So we
> would cache
> InputStream's, DOM's and SAX streams. The only changes in the components
> would be to use SourceUtil, where they currently use their own code.
I think a save way would be too add those methods to the SourceUtil, but
give them a different name (ala cachedToDOM etc), so an implementation
can decide if it wants to use caching or not.
Carsten
Re: Caching in cocoon, especially CIncludeTransformer
Posted by Torsten Knodt <to...@datas-world.de>.
On Sunday 01 June 2003 15:47, Carsten Ziegeler wrote:
CZ> There is already such a component, the cinclude transformer uses this
CZ> for the caching. It should be easy to use that component in the
CZ> xinclude transformer as well.
Yes, I know. But it'S still to much coding for it in the CIncludeTransformer.
Components which need the content of a source, should simply get it, and not
think about caching. It's not their job. Caching is needed in to many places.
All places which use sources, should have caching. It should only be done at
one place for each kind of data.
So what I suggest is introducing SourceUtil.getInputStream for InputStream's
of sources. Then modify toDOM and toSAX to cache their output, to not have
them to parse them first out of the cached InputStream's. So we would cache
InputStream's, DOM's and SAX streams. The only changes in the components
would be to use SourceUtil, where they currently use their own code.
CZ> PS: Could you please not include the PGP signature in your posts to
CZ> this list. It makes reading your mails very hard. Thanks.
Done.
--
Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.