[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