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 Sat, 07 Dec 2002 19:56:31 GMT
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?  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.

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.



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?  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.  The flow script developer is 
conceptually waiting for the function to return just like every other 
function call.  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.

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.

If I have a fundamental misunderstanding of the issues involved, please 
let me know on or off the list.  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.

- Miles

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

View raw message