[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Y Store /Closures



Anton van Straaten wrote:

>Marc Battyani wrote:
>  
>
>>What you call event-driven here looks more like submit-driven to me.
>>IMO event driven is more fine grained than this.
>>    
>>
>
>Web apps are event-driven in the sense that they can't necessarily
>anticipate the requests they're going to receive, and have to be able to
>handle requests in potentially arbitrary sequences - including illegal ones.
>This is the same basic issue that event-driven GUI apps have to deal with,
>even though their events are more fine-grained.
>
Yeah. I was also trying to imply we-call-you rather than you-call-us, 
i.e. whenever an event
happen, a piece of code gets called, and it has to return all the way to 
the "top of the stack"
before the next event can arrive.  Like SAX as opposed to DOM parsers in 
the XML world.
This is what I always think of as the classic case where coroutines are 
useful.

The first time I saw any kind of coroutine was inside MIT's ITS 
operating system, very
cleverly implemented in PDP-10 assembly language, by Richard Stallman 
(I'm told),
in a place where the kernel had just noticed that the user had typed a 
special escape
character, and it wanted to get the next character, but it did not have 
a "stream to read
from", it had to return and then get called back later.  Stallman's code 
used the JSR
instruction in a cool way to save the PC somewhere so that when the next 
character
arrived and the "teletype" input interrupt handler was invoked, it would 
pick up where
it had left off.  It was very elegant, by the standards of assembly 
language coding.

>
>  
>
>>I fire events to the server on slots modification so that I
>>can control more precisely what the user does. In this case
>>continuations don't apply.
>>
>>I am the only one here to do such kind of web applications ?
>>    
>>
>
>One of the systems I've been working on uses a set of Java widgets which are
>embedded in the web page.  The Java widgets communicate with the server via
>HTTP & XML for things like validation etc.  These interactions are
>standalone, so as you say, have no need for continuations.  However, the
>overall flow between pages could still benefit from continuations.
>
>This probably mirrors many GUI apps - events happening within a GUI form
>don't require much context other than the values directly affected; whereas
>movement between forms may involve much more historical context of the sort
>that continuations support.
>
>Anton
>
>
>  
>