cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: Changes made to flow system.js
Date Sun, 08 Dec 2002 18:13:14 GMT
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 

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

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.

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.

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

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

 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 

>> They all can timeout.  They all block/wait for data before returning.
> Agreed, but the usual web developer doesn't think that way: he 
> *expects* to require to save state by himself/herself. 

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 

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.

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

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.

> If you ask me a page, I give it to you with
>  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. 

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

> 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:
For additional commands, email:

View raw message