>> 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.
<small snip/> Yes, but my point was that there may be other things than the browser and the server that you may still want to abstract out in the flow: call this resource to process the credit card validation, but it will go to some mainframe or whatever... I'm not sure I'd want to add this capability, but it nags at me that it might be useful? <snip> >> 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. Ok, I see what you mean. I guess I'd go the other way. If the contract has to be explicit anyway then you might as well make it as efficient as possible and get the indexed lookup that's possible with unique names... >>> >>>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? Well, no and no; the uniquely named resource is matched independent of the sitemap match pattern, the URI matches against the pattern. They both should map to the same place (contractually speaking), but one does so explicitly and the other indirectly (via the sitemap matching rules). >> 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. Well, if we're using a URI then it seems legitimate to extend it with a "protocol" in the same sense that the sitemap currently supports the Cocoon pseudo protocol. Thus, Cocoon:uri ends up going to the sitemap, Gunk:uri ends up going to some other systems URI resolver. You can't really do this with explicitly named resources since you don't know that the other system supports "names", but you do know that it supports URIs... <small snip/> >>> >>>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. Sure, and if/when Cocoon gets the XSLT document caching issues cleaned up that would help. Otherwise, this is a pure XSLT model on our side... >> 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. Gee, that sounds awfully like a procedurally oriented point of view :-).... Ultimately we end up using probably 95% of our metadata and probably 75% of the data, so we're pretty likely to end up referencing it in any case. Whether building some look aside cache, adding a reference scheme, then looking it up as needed would actually end up saving us anything seems doubtful. Ultimately the space time tradeoff here isn't much of an issue either way so it's simpler just to throw everything into the air in a single well defined spot. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
