Re: [HACKERS] Re: XML (was: 2 patches) - Mailing list pgsql-hackers

Tom Lane wrote:
> 
> 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.

This is what DOM is for, read on.
> > 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.)

The XML parser is in the browser. It parses to XML-code into a DOM which
is easily accessed from javascript.

The step are:
1/ a DTD defines the parsing of our document type into the DOM
2/ a style sheet determines the layout on our output device
3/ javascript access to the DOM for making tweak to layout and
functions.

The client side is still immature and some parts are in still flux.

> 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.

This is a chicken-egg problem,
we must have data to make clients interesting
and
we must have clients to make server output interesting

CORBA has the same problem, we must start somewhere.
As I am a "server-side kind of guy", I will start there
and hope clients catch up.

On the client side I put most faith in "Gecko" 
the new layout engine from  mozilla.org.

> 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.

HTTP and/or IIOP/CORBA is useable for that.

> 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.

One does not rule out the other,
I think that much of the object functionality 
of both ideas has much in common with seperate
output mechanisms, like:
---------------------------------------|             PgSQL Core              | ---------------------------------------|
 Object Data Access     | Base     |----------------------------          ||   CORBA    |     XML     | protocol
|---------------------------------------|               Clients              | ---------------------------------------
 

Anyway, thanks for your input Tom.
Questioning my ideas, forces me to develop them
and fill in the blanks, which is "good thing(tm)".
Keep arguments, ideas and questions coming!
mvh,
-- 
-----------------
Göran Thyni
This is Penguin Country. On a quiet night you can hear Windows NT
reboot!