Re: [SISCweb] Session attributes vs SRFI-39 parameters

On 5/3/06, Victor Rodriguez <[email protected]> wrote:
> Hello,
>
> Now that SRFI-39 parameters can be used instead of session attributes,
> I find myself wondering what advantages one approach has over the
> other, or whether SRFI-39 parameters really are a good idea at all for
> a SISCweb application.  Alessandro, could you maybe contrast the two
> approaches?

The main difference comes down to session attributes existing in a
single, global (per-user) scope. SRFI-39 parameters really have two
scopes, one lexical and one dynamic.

The lexical scope is useful to avoid name collisions -- where two
modules of the same application use the same session attribute name.
The Counter example shows a parameter in the module scope.

The dynamic scope, controlled through parameterize, allows to avoid
collisions on the same datum between two parallel navigation flows by
the same user. For instance the Counter example can be navigated in
two tabs, and the counter in each incremented separately. This is less
easily achievable with just the session object.


> Also, I do not understand the following quote (from
> http://siscweb.sourceforge.net/docs.html):
>
> "SRFI-39  parameters are a valid alternative to session attribute for
> tracking state in SISCweb when not using the strict continuation-based
> approach (i.e. send-*/[suspend|forward]."

There seem to be two preferred styles when programming in SISCweb:

- the traditional style of suspending with send-*/[suspend|forward],
collecting request parameters and continuing,
- the more webby, event-based style of setting up closures for all
links with @href-p and the like, which specify what to do next (i.e.
CPS-style).

In the former, variables that were local at suspension will be again
available when the execution is resumed (that's the whole point of
using continuations).

In the latter, only the variables captured by the closure will be
maintained when that link is followed. Meaning that the closure may
have to capture data just for the purpose of passing it to other
procedures that will need it down the road.

For instance Ben Simon describes in his write-up [*] having to pass a
"context" hashtable from closure to closure for this reason.

With forward/dynenv/store! and parameterize one is dispensed from
having to do that, and can instead use parameters (or their accessor
functions: inc*N* in the example) anytime according to their static
scope, and with the "semantics" of their dynamic extent.

[*] http://schemepetstore.pbwiki.com/f/writeup.pdf


> And the AJAX Counter example (counter.scm, from CVS rel-0-4-dev) has
> the following comment:
>
>   ;; "session" variable; note that it becomes "per user" (sort of)
>   ;; only if parameterized at the application entry point; otherwise
>   ;; it would be shared among all users
>   (define *N* (make-parameter 0))
>
> I understand the need to parametize, but what do you mean by becoming
> a *sort of* per user parameter? When would it not be a per user
> parameter? Is it because the user would get a "new" parameter if he
> somehow navigated through the application entry point again?

Exactly. The placement of the parameterize form determines the
isolation of the parameter in respect to parallel execution flows by
the same user. So parameters can be made to act exactly like session
attributes by placing the parameterize at the application entry point,
or as "flow" variables by placing the parameterize at the entrance of
certain subflows.

Let me know if this helps. I may include excerpts into the manual. Thanks!


> p.d. SISCweb is great!

Glad you like it!
___
Alessandro


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642