cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Mon, 10 Jan 2005 16:35:49 GMT
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




Mime
View raw message