From stanpinte at fastmail.fm Thu Jul 22 02:12:55 2004 From: stanpinte at fastmail.fm (Stan Pinte) Date: Wed, 21 Jul 2004 18:12:55 +0200 Subject: [albatross-users] some architecture questions Message-ID: <1090426375.16455.58.camel@pablo-fat> 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). -2: albatross do not handle the "back" button, as it is based on a "state machine" for page flow control. Any workarounds for these stuff would be of great interest to me. thanks a lot, Stan. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From neel at mediapulse.com Thu Jul 22 02:54:16 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Wed, 21 Jul 2004 12:54:16 -0400 Subject: [albatross-users] some architecture questions In-Reply-To: <1090426375.16455.58.camel@pablo-fat> References: <1090426375.16455.58.camel@pablo-fat> Message-ID: <1090428855.9179.14.camel@mike.mediapulse.com> On Wed, 2004-07-21 at 12:12, Stan Pinte wrote: > -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). Albatross is a toolkit, you use what you want built how you want. It's no trouble at all to grab dbpool.py and use it with albatross. Albatross itself has no awareness of a database at all, so this is like saying "Apache doesn't do database pooling". > > -2: albatross do not handle the "back" button, as it is based on a > "state machine" for page flow control. Dependant on how you build you application, and which session scheme you use. We use Albatross in all kinds of public sites, where the back button is just fine. Remember the http in and of itself is stateless, so *no* system http based is going to be 100% stateful, they all make assumptions and trade offs. The difference with albatross is that you can choose which method is right for you. That said, take it out of "theroy" and apply it to real world problems and there is always a solution for maintaing state, so this really has less to do with the tool and more to do with the design of the application. > > Any workarounds for these stuff would be of great interest to me. > Better if you offer up your exact problem to the list, and you'll get more help. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From djc at object-craft.com.au Thu Jul 22 09:40:41 2004 From: djc at object-craft.com.au (Dave Cole) Date: Thu, 22 Jul 2004 09:40:41 +1000 Subject: [albatross-users] some architecture questions In-Reply-To: <1090426375.16455.58.camel@pablo-fat> References: <1090426375.16455.58.camel@pablo-fat> Message-ID: <40FEFEF9.2090502@object-craft.com.au> 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 From andrewm at object-craft.com.au Thu Jul 22 10:42:21 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 22 Jul 2004 10:42:21 +1000 Subject: [albatross-users] some architecture questions In-Reply-To: <1090426375.16455.58.camel@pablo-fat> References: <1090426375.16455.58.camel@pablo-fat> Message-ID: <20040722004221.C55003C08F@coffee.object-craft.com.au> >-2: albatross do not handle the "back" button, as it is based on a >"state machine" for page flow control. Have you considered using the HiddenField application models? These store the state in hidden form fields, which effectively "roll back" with the user's use of the "back" button. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/