Upayavira wrote: ...
But we did document that the API of the bean was unstable. Doesn't that mean we can change the API where necessary?Ah, in this case we can. Unfortunately, class's Javadoc does not has this indication.
How do you use Javadoc to indicate unstable?
<p><b>WARNING:</b> This interface is not stable and could be changed in backward incompatible way without prior notice.</p>
:)
I've got it working now, but I've lost linkGatherer functionality and it seems slower.
Add some heavy XSLT transformations. Say, calculation of number pi :)
I've started looking into reimplementing linkGatherer, by, every time I see cache.store() saying something like (using pseudo-code):
if (objectModel.contains(LINK_GATHERER_LIST) {
cache.store(key + "/gathered-links", objectModel.get(LINK_GATHERER_LIST);
}
Does that seem reasonable?
I don't know what this code is for. I guess for caching of the collected links... Are they used later on anywhere?
Is it easy to build up the 'key + "/gathered-links" ' composite cache key?
It should not be too hard. You can benchmark this using some simple stand alone program.
* Make Cocoon work with an external Cocoon object, again for the sake of a PublishingService
I don't get this. What Cocoon with which external Cocoon?
This is something that Unico talked about in relation to a publishing service running within a Cocoon servlet. Again, I'll wait until we've got an actual plan for such a service.
Ah, I see. But there, you will have to go over the wire, as Crawler does. Right?
Reading Unico's recent email, it makes sense to use FOM_Cocoon if the bean is to be used in a servlet environment. Then the bean becomes something quite simple. Would you agree?
Using flowscript's FOM_Cocoon to process requests? Yes, sounds right.
* work out how to implement Vadim's idea for a single pipeline with an XMLTeePipe to generate both a link view and page view in one hit
Yep. Should increase performance and conformance!
I've spent some time trying to work out how to do this. It seems quite complicated. As each pipeline, when built, is made up of generator, set of translators and serializer, to build a pipeline which splits into two, one half completing normally and the other going off into a separate 'link-view' pipeline, would require a specifically built Pipeline class, and would require changes to the treeprocessor to be able to build it. Am I right, or do you know of a simpler way?
You are right. As currently sitemap implementation adds link gatherer automagically, in the same way links view should be automagically assembled and attached at the branch point.
But to do it automagically would require significant changes to, probably, AbstractProcessingPipeline, as for automagicallity, you couldn't add a special 'BranchingCachingProcessingPipeline'. Is that what you would propose?
Probably, yes, AbstractProcessingPipeline will require support for ViewTee... I'd not create special BranchingCachingProcessingPipeline if modifying of existing classes is easy enough.
Vadim
