Re: some architecture questions

Stan Pinte wrote:
> hello,
> 
> I friend of mine, heavy user of albatross, says it has got two major
> flaws.
> 
> As I think albatross is excellent piece of software, I would like your
> opinion about these flaws:
> 
> -1: albatross cannot do database connection pooling, which kills the
> server in a heavy-access situation. (Indeed, it it runs under apache,
> and as apache is not multi-threaded, we cannot share sessions among
> processes).

Database pooling is not something that the toolkit is trying to solve as 
Michael has correctly pointed out.

> -2: albatross do not handle the "back" button, as it is based on a
> "state machine" for page flow control. 

The precursor to Albatross (Python Fusion) had a feature to protect the 
state machine - it was hard coded as the only option.  We always 
intended adding the feature to Albatross, but have not gotten around to 
it yet.

PF "watched" the HTML generated by the page template and recorded all 
user input options in the session.  When the browser request was 
processed it was validated against the recorded input options.  For 
example, if the served page has an A tage with HREF of "a=3&b=12" then 
the validation would allow the browser request to change ctx.locals.a 
and ctx.locals.b but only set them to 3 and 12 respectively.  Similarly 
the OPTION values in a SELECT tag were recorded so that only values 
served to the browser could be used in the next request.  Each type of 
input method was limited in this way.

PF also automatically placed a "session serial" inside every input tag 
sent to the browser.  This provided a simple way to detect when a user 
was trying to issue a request from an old page.

Albatross supports applications that are not implemented as state 
machines so this "protection" is not always desirable.

The PF method of enforcing browser requests from the most recent page is 
by no means the only way that this could be done.  Another way would be 
to rewrite all user inputs generated in the template so that the input 
fields were uniquely named for every page.  The unique names would then 
by translated from the browser request via a lookup table in the 
session.  For example, the HREF above could be rewritten as "r12345=1" 
then with a lookup entry that said:

	input field r12345 is a static request that equates to
	setting a=3 and b=12.

Every page would then generate new request numbers.  Requests from old 
pages would be detected by a failed lookup of the input fields name in 
the lookup stored in the session.

- Dave

-- 
http://www.object-craft.com.au