[albatross-users] some architecture questions
Dave Cole
djc at object-craft.com.au
Thu Jul 22 09:40:41 EST 2004
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
More information about the Albatross-users
mailing list