Glen Ezkovich wrote:
I've been thinking about why one would want to isolate a blocks flowscripts from other blocks. So far I see two reasons:
1.) some flowscript functions are simply helper functions and should not be directly callled.
2.) a block may use its own classloader and therefore possibly use different versions of a class then the calling block.
If you have other reasons please let me know.
3.) Local pages S,T and U used in a flowscript a defined in a block A should be resolved relative A rather than relative B when used in block B. See Reinhard's earlier mail: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110519369529959&w=2 for an example of this situation, and re-read his and my discussion carefully in the light of this ;)
Resolving relative URIs in blocks relative to the caller rather than the called block will make it hard or impossible to export complete sub flows that do thnigs like creating acounts and what you have.
Another question is of course if we should handle this at the level of exporting flowscript functions. In the begining of the discussion I sugested that it was enough to handle this by calling the flowscript function in the block in a virtual pipeline defined in the block. And only export virtual pipline components from blocks (here I assume that relative URI resolution is solved for VPCs by using the mechanism proposed by Sylvain).
Reinhard pointed out that this will not handle the fact that you often whant to return a result from a subflow, something that is not handled by the pipeline api. Either we could solve this by providing an extension of the pipeline api or by finding an mechanism for exporting flowscript functions. We followed the second way in the discussion.
Providing the result by letting the flowscript function puting it in a session variable is rather akward to use, it is a complicated contract and introduces the possiblity for conflicts between blocks. It is analoguos with replacing functions with procedures that write their result in a predetermined global variable in a program language.
I think the simplest way to handle 1, is to put "private" functions in different files and use the blocks configuration file to distinguish between public and private flowscript files.
2 is obviously a more difficult problem. But this is a problem that is introduced by the dependancy between two blocks whether flow is involved or not. The only way around this is to have the two blocks use the same class versions.
The fact that a block provides a service doesn't mean that it does so only through its sitemap. The service may be provided in many ways. Such as avalon components, sitemap components, VirtualComponents and just POJOs. Blocks are much more about modularization, configuration and deployment then they are about providing isolated services. Once deployed the blocks are part of a web application. If you want to isolate each service then I suggest you look at web services in general and SOAP in particular. You can look to Jini and RMI as well. The problem of independent discoverable services has been solved in several ways. I don't think its necessary to reinvent the wheel to achieve the results you desire.
This is not about reinventing any wheels it is about:
1. Provide the possiblity to package reusable sub flows in a block.
2. Provide a reasonable semantics to using flowscript functions defined in blocks.
3. Keep the possiblity for more "secure" isolation open, if we choose to provide such things in the future.
/Daniel
