Paradigms for CGI application development?

[Scott Penrose]

> How do people get around these problems?  Why is the code for web app 
> UIs very different to that of desktop app UIs?  I suppose some of 
> these problems could be solved if the web server kept the running 
> program in memory across requests (instead of starting a new instance 
> each time), but I don't know of any system that does this.  Are there 
> any?  (And I haven't thought about it much, but I suspect this 
> approach would also be horribly complicated too, albeit in different 
> ways.)

I have seen LOTS of software around for coping with State, and keeping 
the persistence of an object. But in all cases I have not seen the 
concept of your example.

   sub transfer_part1 {
     # ...
     confirm("Really transfer?", "transfer_part2");
   }

   sub transfer_part2 {
     my ($result) = @_;

     if ($result) {
       # DO TRANSFER
     }

     else {
       # ABORT TRANSFER
     }
   }

Where 'confirm' above basically would trigger.

	- Save the current state and location
	- Generate a web page and appropriate URL

And then on return the code would have to

	- Reauthenticate the request (make sure it is the same user and same 
request)
	- Check it has not timed out
	- Restore states
	- Jump back into location.

Of course the save and restore states are not necessary, the 
application could continue to run (this is the idea of the agents talk 
that Danger gave a few months ago).

Now we can simplify it a little by...

Where 'confirm' above basically would trigger.

	- Generate a web page and appropriate URL to return

And then on return the code would have to

	- Reauthenticate the request (make sure it is the same user and same 
request)
	- Return from the method.

This is tricky but no impossible. The idea is quite nice in that you 
would be generating simple dispatch mechanisms, we now need to only 
know which of the 'agents' we need to talk back to.

The tricks would be around clean up (like all stateful implementations 
across a non stateful protocol). eg: the 'confirm' method would have 
some type of timeout, which then returns with fail somehow.

Also in a normal application, if another application is run, we can 
usually say 'sorry locked, exit the other one first'. We can't do that 
in Web, as it may be that the application is no longer accessible (eg: 
browser crashed and lost session id), so we have to offer the user a 
way of force quitting the application.

There are many bits of software out there to handle state and dispatch 
mechanisms to allow the request/confirm/do or cancel approach above, 
but all that I have seen require new entry points for each, and an 
object to hand around. Has anyone seen any code to do what Michael is 
suggesting above, and jump from the middle of a routine, like you would 
processing in a normal application.?

Scott
-- 
Scott Penrose
VP in charge of Pancakes
http://linux.dd.com.au/
scottp at dd.com.au

Dismaimer: If you receive this email in error - please eat it 
immediately to prevent it from falling into the wrong hands.