Mark,

>Now we get to middleware portion of XML.  Why use ODBC or JDBC when I can
>make my efficient TurboImage calls (with TPI and not adding the Allbase
>layer) and return one or more elements to an application server?  XML can
>eliminate the need for loading ODBC and JDBC drivers on all of your client
>machines.

Okay, I'll bite (taking the risk to show my ignorance, but hoping to get
a chance to learn from this thread)... I have been playing with JavaTelnet
recently, using a Java program or applet on the client side that talks to
a plain old MPE program on the server side by opening a telnet connection
to the 3000...

In my first example, I had my Java client run QUERY on the server side
to perform native access to TurboIMAGE databases and parse the resulting
output for stuffing it into GUI elements (JTextField, JTable, etc). The
Java client kept the QUERY session open (to avoid the typical issues of
http and CGI approaches), sending additional commands as required (and
reading back the responses, of course).

In my second example, I used a custom PROG or NMPRG on the server side
(my first choice was Transact/iX for it's convenient and powerful access
to TurboIMAGE databases). In this scenario, I have complete control of
the server program I/O, so I could enhance my DISPLAY statements to wrap
responses to the client side in XML tags (quite easily)...

What benefit would I get by doing this? Could I use an XML parser on
the Java side instead of coding the parsing myself (using while loops,
if statements and lots of substring() method calls)? Would this give
me additional flexibility or just coding convenience? Would I be able
to "pump" (or relay) the XML responses from my server NMPRG into other
programs, maybe connected to my Java client via sockets or somesuch,
for example when my Java "client" is not an applet but a servlet (run
on the 3000 or another web server platform)?

Any enlightenment highly welcome ;-)

Lars.