[erlang-questions] Is there a way to serialise a running process & resume it later (i.e. continuations)

Adriano Bonat adrianob@REDACTED
Fri Feb 27 01:06:17 CET 2009


http://yarivsblog.com/articles/2008/02/17/seaside-style-programming-in-erlyweb/

My "two cents" :)

On Thu, Feb 26, 2009 at 8:51 PM, jm <jeffm@REDACTED> wrote:
>
>
> Robert Virding wrote:
>>
>>     To support e.g. the back-button behaviour in browsers elegantly.
>>     See the
>>     diverse seaside docs for an example how such a web framework can be
>>     used, and for a good explanation of why and what read "Inverting back
>>     the inversion of control or, continuations versus page-centric
>>     programming (2001)"
>>     http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.3112
>>
>>
>> Seeing the state of a process is kept explicitly in the arguments of
>> the functions implementing it it is easy to save the state of a
>> process and so step "backwards" when you want to. If you wish you can
>> keep a stack of process states and step backwards and forwards as you
>> wish. If the problem is just this then I still don't see the problem.
>>
>
> More explicitly,
>
>  * stored an id as part of the URL call it UrlId
>  * store contexts, {UrlId, Cxt}, as part of a list for an acceptable
> history range, say 10 histories per browser.
>     ie, [{UrlId, Cxt}, ....]
>
>  for an incoming request:
>     extract the id, UrlId
>     case proplist:lookup(UrlId, Contexts) of
>          none ->
>              %% return on error page
>              error_page(no_context, ....);
>         {UrlId, Cxt} ->
>              %% Found state do work
>               make_page(Cxt, ....)
>     end.
>
>
> Something like that should do what you wish. I've glossed over the finer
> points.
>
> Jeff.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list