cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Changes made to flow system.js
Date Sun, 08 Dec 2002 07:41:36 GMT
Miles Elam wrote:
> Stefano Mazzocchi wrote:
> 
>> Hmmm, what happens if I do
>>
>>  sendPage("foo")
>>  getAnswerFor("bar")
>>
>> ???
>>
>> I think that sendPageAndWait() *is* atomic once you get it. Separating 
>> the two doesn't sound like SoC anymore if you can mess up like above, 
>> it becomes FoC (fragmentation of concerns) which is bad
> 
> 
> Forgive my interruption, but what does atomicity have to do with this at 
> all?  Unless I missed something fundamental to the flowscript examples I 
> have seen, they are all single-threaded paths of execution.  Atomicity 
> in the database sense is only difficult when you have multiple clients 
> working on the same dataset.  If there is only one client, even flat 
> file datastore access is atomic.  Atomicity in programmatic logic is 
> only necessary when you have multiple threads/processes accessing a 
> common resource.
> 
> sendPageAndWait() still sounds like too much implementation detail to 
> me.  Do you execute executeQueryAndWait() to a database connection?

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 
> function still blocks until the database has enough time and resources 
> to respond.  sendPage() (or just about every other function name method 
> thus far) strikes me as an intrinsically atomic construct by virtue of 
> the fact that it is executed in a single solitary path of execution.

I think I abused the term 'atomic' for this.

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

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

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.

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.

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.

So, what I called "atomicity" is the fact that two operations:

  1) sending the page
  2) keeping the state

were done at the same time, without having the user to think about it 
explicitly.

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)

> The only problem I see with getAnswerFor() is that a page may not return 
> information other than a continuation id (eg. license agreements, 
> general status pages detailing your information up to a certain point, 
> etc.).  However, even with getAnswerFor() and sendPage(), I doubt it 
> would be too terrible to simply set a flag whenever sendPage() is called 
> so that if getAnswerFor() is called after it, it fires an exception 
> alerting the developer that he/she can't do that.
> 
> On a similar note, what is the use case for calling sendPage() (without 
> the wait) and then sendPageAndWait() later?  I think I missed that part 
> of the discussion in the archives.  Once you send a response in a web 
> model, you can't send another with the expectation that the client is 
> still listening.
> 
> This is the reason I proposed sendLastPage().  Semantically it implies 
> that no other requests will be sent from the client regard this extended 
> conversation; The give and take is over.
> 
> So:
> 
>  sendPage(foo1);
>  sendPage(foo2);
>  sendPage(foo3);
>  ...
>  sendPage(fooN);
>  sendLastPage(finishfoo);
> 
> Conceptually, all of them block until the sendLastPage() call. 
> Semantically -- at least in my mind -- it makes no sense to send a page 
> after the last (non-blocking) page.  Does it make sense to send two last 
> pages?  No.  Does it make sense to send a page after the last one?  No. 
> Conceptually *very* simple for the end developer.
> 
> 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.

> Granted, the point of the code is usually for the benefit 
> of the user, but in this case, the focus is on the script developer. 
>  From the script developer's point of view, how are database 
> connections, network connections, filesystem accesses, or user form 
> inputs any different from one another?  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.

> 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 the user doesn't respond, a timeout occurs that
> interrupts execution just like when a database becomes unavailable and 
> the exception breaks the flow of execution.

Wrong.

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.

> I don't mean to butt in when I haven't contributed to flow, but as I 
> will be a user of this API, obscure function semantics aren't going to 
> make my life easier when I teach others how to use it.

Maybe with this more information the picture changed somehow.

> If I have a fundamental misunderstanding of the issues involved, please 
> let me know on or off the list.

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

> A URL or book reference will do.  But I 
> fail to see the logic in enforcing wait/block denotation to the function 
> name when connotation is already there in a function call.

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.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message