cocoon-dev mailing list archives

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

Oh, I see your point now. Hmmmm, hmmmm, hmmmm (cogitating mode)

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

Hmmmm, hmmm, hmmm, ok, ok, what about something radically different like


to replace sendPageAndWait()?

I think Miles has a very good point in underlying the fact that 'send' 
and 'wait' might have semantical collision in respect of 'reinversion of 

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

Yes, I think I see it now.

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

No, but I want people who couldn't do web programming in the past to be 
able to do it with cocoon.

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

Oh, yeah, 100% agreement on that :)

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

Good point.

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


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


Hey, dude, we are in violent agreement here :)

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

All right.

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

never say never. You got me thinking about the fact that

  "sendPage" has an intrinsic stateless meaning


  "AndWait" has an intrinsic statefull meaning

but, together, they collide.

So, let's step back for a moment and think about it coherently: if you 
had a command line application would you write




I think we should focus the attention on the 'data getting back' not on 
'our page going to the client'

besides, page is too related to publishing... gosh, we are so into 
publishing we don't even notice anymore.  Thank &deity; this list is 
full of very skilled devil's advocates :)

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

Again, I think you have a point here.


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

You got me thinking that 'sendPage' (with and without 'AndWait') is 
wrong semantics because it focus the attention on getting the page out, 
instead of focusing on waiting until the data is received.

'waiting' in a continuation-wise sense, of course.

i think that if we focus our semantics on the 'way-back' from the client 
instead that on the 'way-up' to it, we might gain further explicitness.

What do you people think?

Stefano Mazzocchi                               <>

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

View raw message