Wirt wrote...
>I have been observing the wide range of responses to this particular thread.
>Mark's original criterion was to be as simple as possible. However, some of
>the responses haven't been particularly simple, especially if the goal is
>"present the data (from an IMAGE database)". Many of the responses have been
>more along the lines of creating a full-function, e-commerce site. If that
>isn't what Mark is asking for, such solutions are quite substantial overkill.

Very good point. It seems to me that many of the trendy technologies used
in the web arena, are pretty far from being simple, easy to learn or easy
to troubleshoot. Although this might depend on the prior knowledge of the
person who wants (or has to) design or implement the solution. If (s)he
comes from the PC camp, things like ODBC might be "bread and butter" and
COBOL or Transact might be "frightening". If (s)he comes from the MPE side
of the fence, it might be just the other way round. (Java maybe somewhere
in between :-)

Notice that I am only talking about the learning curve here, not about the
actual complexity of the host-based or client-server-based implementation.

What I did like about the thread is that it showed the large number of
different approaches that different people consider viable or at least
potentially interesting for a web based implementation involving the
HP 3000 and it's data. Didn't we have a lot of complaints in the past
that there is not enough choice as soon as the HP 3000 is involved?

(Not that I think that lots of different options for implementing a
solution make it easier for the designer/implementor... And we did not
even have CORBA or DCOM suggestions in that thread ;-) ;-)


Wirt continued...
>Browser presentation of data is extremely simple and can be done by using
>virtually any language or report writer on the HP3000, if that's all that
>desired. All that needs to be done is prepend and append a very small bit of
>fixed HTML code to any report.
>
>An example of this sort of thing I put together for a customer a couple of
>years ago is at:
>
>     http://aics-research.com/tony.html
>
>Putting this page together was done in five minutes -- and could have been
>automated in five minutes more. Using a browser of choice, look at the source
>file. The basic data file that lies between the <pre> and </pre> tags is
>report the way that it has always been written on a line printer for the last
>15 years or so.

One gotcha of the <pre> ... </pre> approach that hit me sometimes in the past
is special characters like < or > or & that have to be taken care of to avoid
confusing the web browser. This can be done by replacing them with appropriate
sequences like &lt; or &gt; or &amp; (IIRC) -- so there isn't a fundamental
issue about it, one just has to recall doing the translation if the "legacy"
report output could contain such "special" characters.

Another approach to get plain text reports accessible to web browsers, if
fancy HTML formatting is not needed, is to just copy the output to a file or
directory that the web server "serves" and use a filename ending .txt which
causes the web server to report MIME type text/plain to the web browser and
thus completely avoiding above "special character issue". Using /bin/tobyte
for copying is advisable as web browsers prefer bytestream files.

I am using the above approach with "xeq /bin/tobyte '-at XY /web/dir/xy.txt"
for making the job listing of our backup jobs accessible to the web server.
This way I can check them quite conveniently (they are not printed to paper).

BTW, if the .txt file are placed in a web server directory that is configured
to allow DirectoryIndex or FancyIndexing (or whatever the web server's config
directive is called), then you do not even need an "index page" that has the
hyperlinks to the .txt (or .html) files. The web server will create one "on
the fly" (from ls -l output). The filenames will be clickable, so it would be
useful to carefully choose the target filenames of /bin/tobyte copying to be
self-explanatory and (optionally) use the sorted order of the "ls" listing,
eg ./backup_sysname_990516.txt in my example.

Lars.