Re: Flow wishlist :)

[Stefano Mazzocchi]

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.

[snip]

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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]