Re: [Webware-discuss] waitforreply()

>
>
>The big question, however, is: what happens to all those threads if the
>average user never fills in the first registration page? ;-)
>
>Paul
>
>
User state should be stored in user sessions, not another thread. You
may need a better session persistance setup, but I think session is the
place to look.
-Aaron

Thread view

Ian Sparks [mailto:Ian.Sparks@...] wrote:
>=20
> You have seen this article linked from the daily python list.
>=20
> http://www.freeroller.net/page/alexkrut
After various local DNS issues, I managed to get a page which looked as =
if
it were some kind of proxy error.
> In it Alex describes using Cocoon and ATCT
> (http://www.velare.com/product/atct.htm) to provide procedural flow to =
a
> webapp.
Patent pending...
> This example in Java :
>=20
> //will send the first registration page and wait until =
user
> submits information
> sendPageAndWait("/registration1.jsp", null);
> UserBean ub =3D getUser();
> ub.setFirstName(getRequestParameter("firstName"));
> ub.setLastName(getRequestParameter("lastName"));
> =20
> ub.setAge(Integer.parseInt(this.getRequestParameter("age")));
> //will send the second registration page and wait until =
user
> submits information
> sendPageAndWait("/registration2.jsp", null);
>=20
> I have to say that I find the idea of this very attractive because it
> makes process flow very straightforward.
I suppose it's a bit like what EasyGui does for Python GUI programming -
instead of callbacks, the developer gets to keep their procedural or
sequential paradigm.
> I wonder if there is a way of programming in this paradigm for =
Webware?=20
I can imagine that it's possible generally by treating your server-side
resources almost like clients, with a communications layer as an
intermediary, giving control to those resources and then suspending them
when they call back into the layer to send a response to the actual Web
client. You can certainly achieve this "reentrant calling" with various
distributed object technologies - I managed to do it with ILU years ago.
As for Webware, I suppose one would have to change the way threads are
employed and to extend the session management to permit communication =
with
existing threads representing "open" activities. I once saw a reference =
to a
paper or article employing generators in a novel way, too - I think =
Aaron
Watters was the author, but I can't find a reference to it on Google.
The big question, however, is: what happens to all those threads if the
average user never fills in the first registration page? ;-)
Paul

Paul Boddie [mailto:paul.boddie@...] wrote :
>>
The big question, however, is: what happens to all those threads if the
average user never fills in the first registration page? ;-)
<<
I believe the ATCT acts as a virtual machine able to suspend threads to =
disk until they need to be re-activated. You might get a few "thread =
files" lying around on disk but they don't take up any other resource =
while they're inactive.
>After various local DNS issues, I managed to get a page which looked as =
if
>it were some kind of proxy error.
Yes, I've been getting that too though it looks like its back up now. If =
not do a search on " sendPageAndWait("/registration1.jsp", null);" in =
google. The only cached result is Alex's page.
- Ian Sparks.

Aaron Held [mailto:aaron@...] wrote:
> >
> >The big question, however, is: what happens to all those threads if =
the
> >average user never fills in the first registration page? ;-)
> >
> >Paul
>
> User state should be stored in user sessions, not another thread. You =
> may need a better session persistance setup, but I think session is =
the=20
> place to look.
Yes, threads encapsulating user state may seem very "sexy", but I'd
personally not use that approach, especially given the stateless, "no
guarantees" aspects of the average Web application.
Paul

Ian Sparks [mailto:Ian.Sparks@...] wrote:
>=20
> Paul Boddie [mailto:paul.boddie@...] wrote :
> >
> >The big question, however, is: what happens to all those threads if =
the
> >average user never fills in the first registration page? ;-)
>=20
> I believe the ATCT acts as a virtual machine able to suspend threads =
to
> disk until they need to be re-activated. You might get a few "thread
> files" lying around on disk but they don't take up any other resource
> while they're inactive.
And of course you can periodically delete those thread files, I suppose. =
A
few years ago, people might have been worried about the resource demands
that this approach might take, but in this age of laptops with 0.5GB =
on-chip
RAM and 80GB disks, I would guess that it isn't a problem any more. ;-)
> >After various local DNS issues, I managed to get a page which looked =
as if
> >it were some kind of proxy error.
>=20
> Yes, I've been getting that too though it looks like its back up now. =
If
> not do a search on " sendPageAndWait("/registration1.jsp", null);" in
> google. The only cached result is Alex's page.
I might well take a look. Personally, I believe that a better exposed =
state
machine is really the way to go in Web applications. It may initially be
more succinct to write "workflows" as straight code, but in the large =
scale,
I'd want tools to be able to manipulate the different sequences of =
screens
and the conditions that are tested to send users between those screens.
Paul

>
>
>The big question, however, is: what happens to all those threads if the
>average user never fills in the first registration page? ;-)
>
>Paul
>
>
User state should be stored in user sessions, not another thread. You
may need a better session persistance setup, but I think session is the
place to look.
-Aaron