Stefano Mazzocchi wrote:
No, because there is a state-preserving channel (a connection) between you and the database. On the web or any other REST-architected networks, we don't.The Cocoon developers don't, but the script developer *does*. The Cocoon developers have implemented it. The fact that TCP is maintaining the connection or a continuation id doesn't much matter to me. The state management may be some smoke and mirrors, but it's an effective illusion.
Look at what sendPageAndWait() is supposed to do:
1) create the continuation object
2) store it someplace
3) get its id
4) invoque the sitemap with the required URI
5) pass the invocation parameters and the continuation id
Okay, so I think I did understand the implementation.
Guess what? it doesn't wait at all!But there is the problem. Folks will have to know about continuations. The sitemap declarations that I have seen require the visualization of continuations and not wait states.
If it waited (say, stopping the execution of a java thread) we would not be able to scale massively! (and this is the reason why nobody with a grain of salt even proposed to stop thread execution on the server side!)
The point of sendPageAndWait() is to mislead. It is meant to mislead in a benevolent manner, but mislead nonetheless. So instead of needing documentation on not explicitly saving state, you'll need documentation assuring that you aren't blocking threads per execution (if they are excluded from and ignorant of sitemap concerns) or documentation explaining why the function talks about waiting when they know continuations are used. Or, as is the case I detail below, has an unintended meaning. *
The issues that people have had in preventing all members of a team from the desire to read an understand the sitemap without regard to their role will come up again with flowmap. People want to know how it works. Good developers are many times pathological in their desire to know how something works before using it. Telling them that you are blocking or waiting is not going to satisfy that curiosity -- especially if they figure out that waiting is not even involved.
What I *love* about the concept of sendPageAndWait() is that its semantics don't indicate what the method really does, but what the user is expecting a 'simple' system to do.This does more than not indicate what the method really does. It misrepresents what the method really does. This is an important distinction I think.
Of course, when you call a database you expect to be waiting for the resoult... but web programmers are used to all kind of dirty tricks to be able to keep state and program FSM-like machineries.And web programmers are not used to control of the URI-space, processing pipelines, or any of the other aspects of Cocoon that are done contrary to just about any other framework out there today. Believe me, the sitemap took me *a lot* longer to grok than flow has. I am I think a fairly typical web developer, and I know very little about the internals of the flow engine except for some salient points: JavaScript with Rhino, continuations, and calls back to the client using sitemap-specified URLs and continuation IDs. I think you underestimate the ability of a web developer to get this.
My personal experience was that Ovidiu announced a working JavaScript version and a summary of how it works. This was all that was necessary to get me excited. Was I excited because Cocoon had a new way of specifying logic? No. Was it the JavaScript? No. It was because you could specify your multi-page logic as a contiguous block and without worrying about state. This was the hook. This is why I believe other people will be hooked.
People who don't get that flow saves state aren't using flow. When you read the docs, when you look at the examples, and when you talk to coworkers, you will realize that you never explicily deal with state. I'm not disagreeing with your conclusions. I'm disagreeing with your premise that people will move to use flow *at all* if they don't know that it handles state and eliminates "all kind of dirty tricks."
So, this is the reason why I think it's cool to specify "AndWait", because if you say "sendPage" people will think: ok, I have to save the state myself.* That is not at all what I thought when I saw AndWait. AndWait holds no implication of saving state to me. Am I alone here? I don't see the association. Wait != SaveState to me at all! When I saw AndWait, I immediately assumed that you meant "wait for user input" and not "make the thread wait."
Yes, we have all struggled with programming methods on the web. We are all too familiar with the series of web pages that accumulates hidden form field after hidden form field. There are developers out there who will still use that model even after flow is in a stable release. As a matter of fact, if people use Cocoon's flow, they were most likely aware of its state-saving virtues before they started. After all, if you are Joe Shmoe web developer, and you didn't know about state saving in flow, why would you ever think to use Cocoon's flow? Honestly.
Several people proposed to have two different methods, one for sending the page, one for saving the state, but it becomes problematic since this separation can be abused (see my example above)
I wholeheartedly agree.
...which you are trying to hide and smooth away for the sake of the web developer. Do you see a difference in that database connections are likely to remain open during transactions while web users make no guarantees that page2 follows page1? I used to until the flow engine appeared.My fundamental question is this. How is blocking on user input any more special a case than blocking on database, network, filesystem, or any other data?like I said, the intrinsic stateless nature of the web.
From the point of view of the flow script developer, page2 does follow page1. The fact that the web client can hit the back button or jump to an unrelated page has no effect on the flow script developer's work. Due to the excellent work of the Cocoon developers, the flow script developer doesn't need to care anymore. He/she doesn't need to worry about clobbered cookies or expired POST data because of a back button anymore.
I don't agree. I don't think they expect to save state *when using Cocoon's flow*. None of the examples explicitly save state. The documentation talks about removing the need for explicitly saving state. I worry that you underestimate the deductive ability of the average developer.Agreed, but the usual web developer doesn't think that way: he *expects* to require to save state by himself/herself.They all can timeout. They all block/wait for data before returning.
Cocoon has pulled the rug out from under developers over and over again with great ideas that run contrary to web development norms. Compared to pipelines, the sitemap, actions, etc., flow seems a no-brainer to me. You seem to be obfuscating something that was clear to begin with -- probably more clear than just about any other concept in Cocoon.
Yes. It is. But not a difference with which you must bludgeon developers over the head repeatedly. Do you honestly believe that if someone has written any code for the web at all, flow will suddenly make them forget that there's a client on the other end that must explicitly request page2 and something referring to their work with page1? In the unlikely event that it did, the development process would eliminate that thought in a heartbeat. It's a conceptual difference that doesn't require assistance from the function names to be driven home.The flow script developer is conceptually waiting for the function to return just like every other function call.Yes, but you are not doing RPC, dude. it's not you calling somebody, it's somebody calling you! Big conceptual difference.
If you ask me a page, I give it to you withHere I think we may never agree. Yes, execution will not continue. Any resources allocated in the flow script will be garbage collected. I simply fail to see how this is any different *for the developer* to a servlet exception firing in a service function that throws. Before anyone jumps on me about that, I realize that you can't just put a try/catch block around sendPage(). This is where logic with continuations differs from Java and standard JavaScript. But again, I don't see why this item in particular is something any developer would be helped with AndWait(). If they don't get the web model or continuations, AndWait isn't going to make it any clearer. If they do get continuations, AndWait() is confusing.
sendPageAndWait()
and you go home, that continuation will simply expire, the execution *will not* continue.
This is a *very* different behavior from any blocking I/O paradigm. And this is because it's not your code to be in control.
In fact, they used the term 'reinversion of control' to describe the architectural concepts behind continuation-based web logic.
Maybe with this more information the picture changed somehow.It has definitely helped me understand your point of view. I still don't agree with it unfortunately.
I think you are failing to see that there is a (admittedly subdle) difference between flow control (when you drive the I/O request) and reinverted flow control (when you 'fake' the fact that you drive the I/O request, but in fact, you are not).On the contrary, I believe I did get that. I simply don't see why this difference is relevant to practical scripting. If you're faking the driver, why not commit? From the developer's point of view, what fundamentally changes when they actively ponder reinverted flow control versus a simple return from a function? Was the focus for this exercise that they grok reinversion of control or that they have as simple as possible model for advanced web development?
If there is no substanitive code difference (function names don't count in this case), are there security issues or functionality issues involved if the developer doesn't 'get' it? If so, flow has bigger problems than a function name. If not, then let me give this analogy. Why does a beginning Visual Basic Script developer on IIS+ASP need to know how COM works (AddRef and Release, ApartmentThreads, DCOM) and all of the issues involved that prompted the development of COM? The truth is that they don't by and large. It isn't necessary to the model. And as point of fact, because the implementation (actual or simulated) isn't advertised, ASP development both on the client side and the server side are simpler to handle. Sure if you're just starting out, you don't realize that because of the underlying web model, you must send custom headers and/or redirects before sending any content. But this doesn't matter. So much work can be done and is done without this knowledge and without explicit tag semantics saying in effect, "Start output of content now." It is implied for the common case.
You definately have a good point, but I fear that web programmers are so used to stateless environments where functions that return pages to the client are not blocking (in fact, the act of sending a page frees the thread!) that we need the extra working to make sure they see a difference in what they are used to.Two possible scenarios:
(1) They heard about this "flow thingy" and read the main documentation page. Here they see that state is automatically saved and logic is conceptually one contiguous block. If they don't get this after reading the page, they aren't going to use flow. Once again, what would be the point if they don't get it in the first place?
(2) Flow is already in use at an organization. As soon as someone asks, "How or where should I save the state when I go to the next page?" alarm bells sound in coworkers' heads and they direct the person to the docs or just say, "No need to do it yourself, because it does it for you."
Who uses anything unless they've researched at least at a minimum what it can do, how it compares to other models of web development, or your job makes you use it (presumably with someone who has done some basic research)? Who ever says, "I hear that ProjectX does web stuff. I think I'll start using it right now without doing any type of research or prep work"? (Or rather, who that you would actually ever want to work with... Any CTO that pushes technology without any reason or research is dooming a company anyway.)
I do not see a third scenario where someone is using the flow engine but doesn't have someone else on hand who already gets it, hasn't understood why they want to use it, or what benefits it gives over standard web development models. If they don't have any of those three things, what would prompt them to even get to the point that AndWait() would even be looked at?
However, this is of course my opinion, and I won't press the point further. If I've failed to sway you by now, I probably never will. I'll still use the flow engine either way. :)
- Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
