Thanks for your indepth and patient response!
My name is Carl E. McMillin and I'm still establishing my balance in this
particular knowledge domain with its nomenclature and entities.
> The term "App-server" is very commonly used to describe
> the container where the application logic resides. As such,
> an app-server has access to one or several Storages. PostgreSQL
> is an implementation of such a storage. The thing you describe,
> "a container for functionality that persists control/data state
> beyond a single invocation" is also a Storage.
Essentially, I agree with your assessment: App Servers should do app-stuff
and Storage Servers (RDBMS engines for instance) should do storage stuff.
But Postgres isn't purely a storage solution; it is not just a place to hang
your data. Aren't stored procedures, whether SQL-based or backed by native
libraries, very much essential to application-logic performance and
portability? Ok, portability may suffer, but they do help performance!
Perhaps tiers which include "extreme" Postgres are not as clearly delineated
in function as a DBA or a systems engineer would like, but the extensible
nature of Postgres does lend flexibility to the developer looking to offload
complexity into the database so that the functionality is as accessible as
the data operated on.
One of my personal interests is "hybridizing" a strong SQL
execution-environment such as Postgres with an equally strong
process-control framework so that components which would normally be in the
"middle" tier are directly accessible by way of "extensions". For instance,
constructs such as the following would be really useful in some
bioinformatics-related consulting I'm involved in:
SELECT * FROM get_list_of_hsp_from_blastall('ACGGATTAT', 'H_sapiens');
The function "get_list_of_hsp_from_blastall" takes a primer ('ACGGATTAT')
and an organism ('H_sapiens') and runs an external process called "blastall"
to locate "high-scoring pairs" where the primer "aligns well" with the
organism's nucleotide-sequence (its genome). This would be a relatively
trivial exercise if Postgres had a robust framework for process control -
maybe it does, I haven't gotten many responses indicating yea or nay.
Anyway, I'm on for anything in the way of enhancing this aspect of Postgres
if there is sufficient will for such in the community. The moniker under
which this development takes place I leave to better minds.
Best Regards,
Carl <|};-)>, CarlCo, (Newbie) Computer Engineer.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Hallgren
Sent: Saturday, June 12, 2004 1:12 PM
To: [EMAIL PROTECTED]; Carl E. McMillin; [EMAIL PROTECTED]
Subject: Re: [HACKERS] I just got it: PostgreSQL Application Server -- a new
project.
The term "App-server" is very commonly used to describe the container where
the application logic resides. As such, an app-server has access to one or
several Storages. PostgreSQL is an implementation of such a storage. The
thing you describe, "a container for functionality that persists
control/data state beyond a single invocation" is also a Storage.
It's very common that you impose a separation of concern that imposes 3 (or
more) layers (3-tier, n-tier). You have the backend tier, a middle tier, and
a client tier. PostgreSQL inherently belongs in the backend tier. An
app-server is more or less always considered to be the thingy that lives in
the middle tier.
The ability to persist the state of a session, efficient handling when
storing HTML/XML, and cluster capabilities, will make PostgreSQL an
excellent backend for many app-servers that can utilize that kind of
functionality. It will not however, make PosgreSQL an app-server in itself.
I really think that [EMAIL PROTECTED] has great ideas (B.T.W. it would be
nice to know your name) and I'd be happy to help out if this project takes
off. But some other name for it would be preferable.
Kind regards,
Thomas Hallgren
----- Original Message -----
From: "Carl E. McMillin" <[EMAIL PROTECTED]>
To: "'Thomas Hallgren'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Saturday, June 12, 2004 20:24
Subject: RE: [HACKERS] I just got it: PostgreSQL Application Server -- a new
project.
If you consider an app server as a container for functionality that persists
data/control state beyond a single invocation, PostgreSQL (and lots of other
DP solutions, of course) falls into the category already, ne?
I suppose my def. is too gross, but I agree with [EMAIL PROTECTED]'s
conjecture that Postgres COULD provide "externalization" hooks so that the
SQL engine could integrate external services/data-sources without
recompiling the backend, postmaster, or any other kind of major (and
dangerous) restructuring.
I believe that some of the contribs (like PL/Perl) have functionality for
controlling external processes from stored-procedures, but this kind of
functionality should be in the "kernel" of the engine, in my mind.
If I'm totally offbase, plz correct.
Carl <|};-)>
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Hallgren
Sent: Saturday, June 12, 2004 9:47 AM
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] I just got it: PostgreSQL Application Server -- a new
project.
Even if I find the concepts as such very interesting, I think the term
"Application Server" is very misleading. People would get very confused and
place PostgreSQL in the same category as JBoss, Jonas, Apache Geronimo, IBM
Websphere, BEA Weblogic to name a few well known App-servers.
IMHO, you really need some other umbrella name for this.
Kind regards,
Thomas Hallgren
""Carl E. McMillin"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Jumping on that bandwagon with all 6 feet!
Carl <|};-)>
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 9:38 PM
To: [EMAIL PROTECTED]
Subject: [HACKERS] I just got it: PostgreSQL Application Server -- a new
project.
I have been harping for the last few days (years, actually) about tweaks and
changes to PostgreSQL for a number of reasons ranging from session
management to static tables. I even had a notion to come up with msession on
PostgreSQL.
I have been incorporating full text search, recommendations, and a slew of
other features into PostgreSQL, but you know what? While it does touch
Postgre in a real sense, it is not strictly SQL. It is about how to create
applications with PostgreSQL. That's what we're missing, Coneptually,
PostgreSQL is strictly a database and the core team (rightly so) is
fundimentally happy with that aspect of it.
Maybe we need a pgfoundary project called "PostgreSQL Application Server."
Like Apache Tomcat or regular apache or PHP, PostgreSQL could form the SQL
base of a far more intricate and flexable framework that encompases a lot of
the various features that could provide "application sever" features from
PostgreSQL.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
