Ken wrote...

>< smug alert >
>< give-in-to-temptation, may-not-pass-my-way-again alert >
>
>With Transact, automatically walking an "n" level tree using
>IMAGE chains is one of the easy things to do.  An example ...

Thanks for the advice, Ken. Just for the grins, the retrieval
of the "patch successor chain" is in fact currently implemented
in Transact/iX on my machine :-)

I'm just playing with server side Java to see if I can get rid
of the overhead running those Transact/iX database accesses in
a *short-lived* CGI processes...

I'm curious to see the performance difference between the old
style and the new style implementation. If the SQL-via-JDBC type
of access should be too slow (but it does not seem too bad so
far), I might still go with calling native TurboIMAGE intrinsics
or even doing a CREATEPROCESS and keep up a Transact/iX database
engine child that my Java code can talk to via MSG files or alike,
or maybe look for a trial version of ADBC...

Besides learning Java, my idea behind these experiments is to
open a door for supplementing an existing tool/application here.
I feel that server side Java Servlets are much more flexible and
convenient to implement an additional web interface in my case
than going with a CGI based approach, because they stay alive for
longer than just a single http request, can have a "memory" to
implement "stateful behaviour" and the like, do provide easy ways
to parse out URL or HTML form parameters, etc etc.

One nice aspect of server side Java is that I do talk to the web
browser in plain HTML, so the client does not need to have one
of the latest and greatest Java-capable web browsers installed to
use my web interface. This is quite different from an approach
based on Java applets.

:-) Lars