On Mon, Aug 15, 2011 at 5:14 PM, David Johnston <polobo@yahoo.com> wrote:
>> This whole line is getting somewhat off-topic; we're not talking about a "computationally complete" application but
simplyone that can handle HTTP requests and dispatch calls to user-defined methods. This seems like a small-enough
requirementand seems to already have a solution (though I haven't looked at the provided links); whether you call it
PostgreSQLor not is a matter of semantics (as is much of this thead).<<
Which PostgreSQL *can* do, but probably shouldn't.
>> Please restate your request in terms of benefits as opposed to checklist of cool features that barely work but,
becausethey are present, can be added to the marketing materials.<<
The whole thing is: Pg as an app server occupies a *different* role
than a traditional app server. Not better or worse, just different.
Think of it as a database program which can also operate as a message
queue once operations complete successfully and committed. That's a
pretty powerful thing with listen/notify. And you can process data in
additional PL's as well, accessing methods from other languages so you
don't have to reinvent the wheel.
It is my view that PostgreSQL makes an *excellent* application server
as long as you use it intelligently. That means treating the
database as the *central* application and then using it to manage not
only main data storage, but also message queues to other helper
processes which can, for example, send email, print documents, or
whatever.
This is the direction LedgerSMB is moving: using Pg to the max but
doing so carefully and intelligently.
It is not a traditional application server, but it can easily replace
a traditional application server along with helper programs in
whatever languages one wants to write them in. The power and
flexibility is really quite amazing.
Best Wishes,
Chris Travers