Carsten Ziegeler schrieb:
Reinhard Pötz wrote:
I would only make the caching file generator available to the sitemap.
If you put it into a caching pipeline, its caching interfaces will be
regarded, if it is used in a noncaching pipeline, the
CachingPipelineComponent interface will be disregarded.
Hmm, yes, sounds much simpler :)
I'm not sure if it is a good idea to introduce aspect orientation at
this level which adds a further level of complexity.
I also fear that this will not be a solution that works for every
scenario and if it's only one component that can't be cached
transparently by AO mechanisms we get a problem where to put it because
we wouldn't want to introduce a dependency on the caching module.
Hmm, I don't meant real aop - I haven't looked into the caching pipeline
Hmmmm, if not *real* AOP what then?
impl, but I guess it checks each component if it implements the caching
pipeline component interface. If the component does not implement it,
the caching pipeline could try this default behaviour.
Without thinking this through, I see two downsides: the cache key might
contain stuff which is not required (this should be neglectable). The
pipeline ends up to be always cacheable, regardless if the components
itself support caching - this might be not the desired effect - I don't
know :)
I'm not sure I would like a system where I cannot "disable" a feature,
even if I want it.
There might (iow. will) be situations where a result must be
regenerated, even if all input parameters remained the same (just
imagine using a CMS, Database, Index, etc. as input).
If the system keeps using the old result because the query for the DB
did not change, you're screwed...
On the other hand, I guess it would be rather difficult to provide a
caching mechanism with an optional module that can work with virtually
any component that might exist.
Of course we can extract all the caching that exists now into a separate
module but everything that needs caching would have to depend on it.
If we want to clean up the cocoon-pipeline module, it's probably a
better idea to create a 'cocoon-sax' module and we move all SAX related
classes there. Then 'cocoon-pipeline' contains the core interfaces and
the pipeline implementations (incl. caching).
I think we should do both :)
I think we should definitely separate the SAX components from the
pipeline. Especially with StAX coming.
I'm sure this will make the pipeline-module quite small and nice...
Regarding the whole topic
In your first mail you wrote: "there are too many interfaces which might
confuse users"
Mind explaining what you mean?
IMO a user won't have to deal with many of the interfaces at all - even
if (s)he uses the pipeline API directly (iow programmatically), not to
mention when using the sitemap.
Someone who actually deals with the Cocoon code shouldn't have too much
trouble - especially when comparing it to Cocoon 2.x.
IIRC this isn't the first time that someone said "Cocoon 3 is already
too complicated because of too many/much ..." (e.g. interfaces, modules,
complexity etc).
I mean Cocoon 2.x is at least 5 times as much as Cocoon 3 - no matter
what kind of metric you use (I'm just guessing here, didn't actually
measure).
So how come a considerably smaller/simpler approach is suddenly too
complicated or too confusing?
Carsten
