At 08:18 PM 11/18/2002 -0700, Rob Nagler wrote:
We digress. The problem is to build a UI to Sabre. I still haven't
seen any numbers which demonstrate the simple solution doesn't work.
Connecting to Sabre is no different than connecting to an e-commerce
gateway. Both can be done by
cvsuser 02/11/19 14:01:51
Modified:P5EEx/Blue/P5EEx/Blue Context.pm
Log:
fix
Revision ChangesPath
1.41 +3 -2 p5ee/P5EEx/Blue/P5EEx/Blue/Context.pm
Index: Context.pm
===
RCS file:
Stephen Adkins wrote:
So what I think you are saying for option 2 is:
* Apache children (web server processes with mod_perl) have two
personalities:
- user request processors
- back-end work processors
* When a user submits work to the queue, the child is acting in a
Hi Stephen,
On Tue, 19 Nov 2002, Stephen Adkins wrote:
My question with this approach is not whether it works for synchronous
execution (the user is willing to wait for the results to come back)
but whether it makes sense for asynchronous execution (the user will
come back and get the
On Tue, 2002-11-19 at 16:28, Stephen Adkins wrote:
At 08:18 PM 11/18/2002 -0700, Rob Nagler wrote:
We digress. The problem is to build a UI to Sabre. I still haven't
seen any numbers which demonstrate the simple solution doesn't work.
Connecting to Sabre is no different than connecting
Rob Nagler wrote:
My experience is just the opposite. If you reuse code, most servers
contain that code base and are therefore large relative to very
specific applications. Most of our mod_perl servers are 15MB minimum,
and grow to up to 80MB.
But what if the code is not meant to be
Rob Nagler wrote:
The antithesis of this is J2EE, which introduces an amazing amount of
complexity through protocol explosion (is it a Message/Session/Entity
Bean, do I use JMX, JMS, RMI, etc.). It creates tremendous confusion,
and their software is certainly less reliable than Apache.
I
