cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow wishlist :)
Date Tue, 10 Dec 2002 20:49:50 GMT
Hunsberger, Peter wrote:

>>>1) I hadn't really made the differentiation between your semantics and 
>>>mine partly because the term "callPage" implies, to me, a "call" to a 
>>>named resource.  As such, it seems to me that the command to jump out 
>>>of the flow layer should be something more like "applyURI" or 
>>>"resolveURI"; you're not calling a named resource, your resolving a 
>>>URI in your flow?
>>the methods are called 'sendPage*', Peter. We are not calling anything. 
>>We are handling control to the resource production logic which is 
>>contained inside the sitemap.
> Whoops, my bad. I guess it was just all the examples I had seen that seemed
> to refer to a simple named resource and not a URI.  However, "send" also
> seems bad; sort of like "goto" from the evil pre-structured programming
> days... Also, isn't it possible (though possibly rare) that nothing ever
> gets sent and that the invoked resource just does some back end processing
> and then the flow should carry on?

Nop. The web is designed as a request/response media. You *have* to 
return something. Even an empty page, but if you don't, the browser will 
block for a reply. Unlike SMTP, for example, which is designed the other 
way around.

(sidenote, this was the reason why the Servlet API expert group rejected 
Pier and myself's propoal of mergin JAMES' Mailet API to the Servlet API)

>>applyURI and resolveURI don't make any sense to me in this context, 
>>because you are not applying a URI (you are asking for the sitemap to 
>>generate that resource) and you are not resolving a URI (resolving, in 
>>my book, means mapping from one URI to another URI)
> Well the point is, when you dump a URI into the sitemap you may not know
> exactly what resources are going to be matched up against it; thus the
> sitemap "resolves" the mapping of the URI to the resource.  However, I think
> I like the suggestions towards more receiver like semantics, like
> "getUserInput()" or similar.  Though that seems to leave the non-waiting
> version a little orphaned?  Maybe it's a combination of both:
> "getUserInput()"
> and "applyResources()" for the waiting and non-waiting calls respectively?
> Certainly "page" seems wrong, since page oriented media are not the norm on
> the web?

I agree that 'resource' has a more general meaning but I think page is 
good enough in this context.


>>>>This enforces separation. Might be painful at first, but *very* useful
>>>>down the road when you can manage and maintain your flow without having 
>>>>to touch (or being afraid others touch!) the resource-producing 
>>>>pipelines and the URI space (which acts as a contract between the flow 
>>>>and the sitemap, enforcing good use of internal contracts and parallel 
>>>>development between separate teams)
>>>Well, like I said I can see why you want that contract.  The added 
>>>abstraction does provide some useful separation.  The same separation 
>>>can be maintained by using explicitly named resource;
>>Well, you are, in fact, explicitly naming a resource with a URI.
> I don't see that; if it's a URI how you do you know what resource will be
> matched up against it by the sitemap?

true, it's up to how the sitemap is designed.

> Isn't the fact that you don't always
> explicitly know the mapping part of your rational for using a URI and not a
> name?

Nop. My point is: if you know a name of a resource, then you know the 
name of the URI that maps to that resource. This is because you *must* 
have a contract between you using the flow and who designed the sitemap.

My point is: that contract can be identified by a URI space only or a 
URI space plus named resources. I don't see why I need the second, since 
I need to know the URI space anyway.

>>>but why introduce another mapping between the two layers?
>>>The only reason I can see might be for
>>>performance; you can enforce name uniqueness in the sitemap and then 
>>>hash directly to the resource from the name saving the URI resolution 
>>>step.  For cases where you want to really use a URI then you support 
>>>that also, thus you may want both "resolveURI" and "callResource"; one 
>>>which processes a general URI and the other which allows Cocoon to 
>>>shortcut directly to the resource as composed in the sitemap.
>>I see your point, but I don't know why we should make another layer of 
>>indirection... performance aside, do you envision a functional reason 
>>for having that?
> I thought you where proposing the indirection by using a URI as opposed to a
> uniquely named resource?

Gosh, it's the same thing! Are you, by any chance, confonding URI with URL?

> In either case, I can possibly see a reason for
> the indirection: if you want to include other external systems in the flow
> then you can only do it by having a mapping layer that parcels out the calls
> as needed.  In that manner, the flow manager becomes a modular system where
> Cocoon is perhaps just part of the picture and you have a way of plugging in
> other (non-Cocoon) resources.  I would maybe support having a syntax that
> allowed for that as a future possibility (pseudo protocols seem to fit the
> bill) but I can't see that you want to otherwise bite off on that for any
> immediate future release...?

I totally lost you here.

>>>>I would call for 'inefficiency' right there. You are basically sending
>>>>thru *all* your metadata even if you don't know you're going to use it 
>>>>or not.
>>>Well no, I'm still using multiple pipelines to aggregate different 
>>>metadata sources as they are needed for a given resource. So, not 
>>>everything gets processed every time. However, the complexity of our 
>>>business rules does require us to process a lot more metadata than 
>>>other people would ever think rational...
>>Still I don't buy how a 'push model' (I'll send you what you think 
>>you're going to need) can be more efficient than a 'pull model' (you ask 
>>me what you want), but that might well be me.
> The main reason for such a strategy is that back end calls can be expensive
> and given the rules based nature of our system you can't tell what resources
> are required until the rules are processed (eg; you don't know that past
> history is needed until you discover that the user is doing a search on a
> patient who hasn't given the protocol a disclosure agreement).  As such,
> it's much cheaper to grab all the metadata and most of the data in a single
> back end query than it is to do in multiple passes.  

Well, this has very little to do what I was talking about. Your strategy 
to come up with metadata is one thing, how you pass it on to your 
pipeline is a totally different thing.

> This is in fact one of the big problems we ran into with the old system. We
> have, for example, a patient questionnaire that currently makes 19 separate
> trips up and down through the EJB structure just to build the object model
> and 19 more trips to assemble the data.  With the new system we do it all in
> a single trip.  This might seem like a lot of metadata and data but on
> average it doesn't work out that way.  There are exceptions, and we have a
> special object type for the cases where it makes more sense to make a second
> pass.

Great, but this doesn't show me how it could be faster to throw this 
data inside the pipeline instead of keeping it in memory and have the 
pipeline access it when it needs it, instead of throwing the whole thing 
inside the pipeline.

Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message