Miles Elam 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.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.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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
