cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <g...@hard-bop.com>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Tue, 11 Jan 2005 01:18:19 GMT

On Jan 10, 2005, at 10:35 AM, Daniel Fagerstrom wrote:

> 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.

OK. Don't you think that if we are the calling block we could specify 
what our block is and use that as the URI. i.e. 
myForiegnFunction("block://caller/path/To/Resource") We could do this 
for using resources from any block. I think you can contrive examples 
where this may not work, but I think in the end if you examine your 
problem space you could find a way to declare and implement things so 
that it would in a way that is straightforward.

>
> 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).

This works for me.

<snip comment="I've said all I have to say returning objects. To me its 
simple."/>

>> 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.

I do agree that that is what its about.

> 3. Keep the possiblity for more "secure" isolation open, if we choose 
> to provide such things in the future.

This I think is possible without doing anything. Nothing I've suggested 
prevents this. Lets just get a basic block based deployer working and 
move on from there.

I really think this discussion gets us nowhere until we have see what a 
block manager actually does and we have the semantics of a block 
protocol in place. Until then I really have nothing more to say and 
doubt seriously if what I have said has moved this discussion anywhere. 
I still don't see any problem except that flowscript doesn't have 
private functions. :-(


Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow


Mime
View raw message