Dang, I actually realized I just overlooked something big: my examples
didn't use real closures -- just anonymous functions. With framework
support, those functions could be used as closures and their
environment data could be accessible in subsequent actions without the
controller's using the session store explicitly. I should have thought
a bit harder before voicing my skepticism :) (However, I believe some
of the disadvantages I listed still hold true.)
Yariv
On Feb 12, 2008 10:35 PM, Yariv Sadan <[EMAIL PROTECTED]> wrote:
> My impression (and I could be very wrong because I haven't used a
> continuations-based framework) is that continuations can be useful to
> streamline the code for some multi-page interactions, but for general
> web development purposes they cause too many problems: non meaningful
> URLs, sticky load balancing, no back button support, no crash
> recovery, and apparently also high memory requirements (I'm not sure
> why, but I'll take your word for it.)
>
> Also, I'm not sure that continuations create such a dramatic decrease
> in code size. Consider these two similar examples, one that uses
> continuations and one that doesn't (I'm using the terms continuation
> and closure interchangeably here):
>
> index(A) ->
> form([input("name"), input("age"), submit()],
> fun(A1) ->
> [Name, Age] = [get_param(A1, "name"), get_param(A1, "age")],
> save(Name, Age)
> end).
>
> index(A) ->
> case method(A) of
> 'GET' ->
> form([input("name"), input("age"), submit()]);
> 'POST' ->
> [Name, Age] = [get_param(A, "name"), get_param(A, "age")],
> save(Name, Age)
> end.
>
> Is the first version really that much better?
>
> By the way, you can write code that looks like it uses continuations
> but without any framework support:
>
> index(A) ->
> get_inputs(A, ["name", "age"],
> fun([Name, Age]) -> save(Name, Age) end).
>
> with this utility function:
>
> get_inputs(A, Inputs, Fun) ->
> case method(A) of
> 'GET' ->
> form([input(Input) || Input <- Inputs] ++ submit());
> 'POST' ->
> Fun([get_param(A, Input) || Input <- Inputs])
> end.
>
> I'll appreciate any enlightenment in case I'm missing something big here.
>
> Yariv
>
>
> >
> > I was think of "unrolling continuations". Unrolling similarly to loop
> > unrolling in language compilers. One of the problems with continuations
> > is the amount of memory consumed. I watched a talk off google video by
> > one of the developers of seaside, sorry can't remember which talk, where
> > he was asked how much memory was consumed by the use of continuations.
> > He stated about 2MB per session. He was likely making a "guessimate"
> > based on he's experience and not base on actual measurements but even so
> > that's alot. When you consider that for most sites most of the time the
> > use of continuations is to allow the extra functionality it provides is
> > unwarranted. Being mostly queries of static data versus editing,
> > multipart forms and the dreaded shopping cart example. In fact the use
> > of continuations and the associated session can be annoying. Consider
> > the seaside tutorial located at
> > http://www.swa.hpi.uni-potsdam.de/seaside/tutorial. I aim to read about
> > a page a day, but the session information times out and I have to go
> > back to the first page before finding my place. Very frustrating. It
> > would be much better to have this functionality turned off by default
> > and only turn it on as needed.
> >
> > Anyway, what I was thinking it might be possible to "unrolling
> > continuations" in loose terms. Would it be possible to do this is such a
> > way as to,
> >
> > 1) reduce memory usage
> > 2) be able to turn it on only for a section of code
> > 3) serial to a database such as mnesia, so that,
> > 4) unlike continuations be distributed for the purposes of redundancy
> > and load balancing.
> >
> > Can anyone point be to some good references on continuation so that I
> > can actually get a deep understanding of continuations, etc?
> >
> > trying to run out the door,
> >
> > Jeff.
> >
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"erlyweb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
