Stefano Mazzocchi wrote:
Hmmm, what happens if I doForgive 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.
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
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.
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? 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
