Goran Thyni <goran@kirra.net> writes:
> The pros, IMHO:
> * XML interfaces better to the object model of pgsql itself
CORBA does that as well or better, I suspect.
> * XML interfaces better to XML-viewer, like next generation of
> web browsers.
So? I can't get excited about being able to view raw server output in
a web browser --- it seems to me that any interesting web application
of Postgres is going to involve an intermediate layer of code anyway
(to convert client actions into SQL commands, adorn the output with page
headers and buttons and so forth, etc etc). I don't see anything about
XML that eliminates the need for that intermediate layer, and I don't
see much about XML that makes that layer easier to write.
> With a little imagination we can at some point in the future forget
> about making clients for the databases, just point your webbrowser
> at the serverport a make both SELECTs (displays) and INSERT/UPDATE
> (forms) with a few lines of javascript.
I think you drastically underestimate the amount of glue code that will
be needed, and overestimate the advantage of having the results come
back already formatted in an HTML-like fashion. (OK, it'd make direct
display a little easier, but what if you have to extract some data for
processing? Writing an XML parser in Javascript doesn't sound like a
piece of cake to me.)
If XML had big benefits for non-web-browser front ends, it might still
be a win, but I'm not seeing anything much there either.
It should also be pointed out that XML isn't a *protocol*, just a
data representation. If you choose to represent the results of SELECTs
in XML, that still leaves you with all the other aspects of FE/BE
communication yet to be designed.
I thought the proposal to build a CORBA-based interface for Postgres
was pretty interesting and worthy of further study ... I'd rather see
us put our time into that. (I am certainly not wedded to the current
FE/BE protocol; it gets the job done, but it's crufty and has
performance limitations.)
regards, tom lane
