Hi, Jacob,
Responses are interspersed.
----------------------------------
Richard Conn, ASE and PAL Manager
http://xenadu.home.mindspring.com/
> -----Original Message-----
> From: Team Ada: Ada Advocacy Issues (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of Jacob Sparre Andersen
> Sent: Sunday, September 12, 1999 5:18 AM
> To: [log in to unmask]
> Subject: HTML+HTTP+CGI as a user interface (Was: How to provide Ada with
> the best possible GUI)
>
>
> Richard L. Conn:
>
> > The upcoming Ada and Software Engineering CDROM (which will be
> > distributed to all SIGAda 99 attendees) will have material on
> > this topic, so you can look there for more details.
>
> How do you handle problems like where the CD is mounted and
> other platform/configuration dependencies?
The CDROM is just an information and software distribution
mechanism for the courseware, software, reports, etc. It's
not an implementation mechanism. However, in a different
venue, I did have to address how to handle an integrated
interface that crosses many CDROMs (in this instance) or
one single website (when all the CDROMs are placed together
on a website). GWRL (Generic Web-based Reuse Library, which
I wrote in Ada95, handles this ... it has a CDROM mode and a
"normal" mode). It is included on the ASE CDROMs and websites.
The upcoming ASE CDROM will contain GWRL with a Visual Basic
front-end, so you can run the GWRL family of programs from the
command line or with a VB GUI over them.
>
> Can you run the CGI programs on the local machine, or do you
> simply link to CGI programs on a server somewhere on the
> Internet?
I can do either, altho with the CMM Level 4 data collection
system, my CGI programs are on a web server separate from the
client. If you want to run them locally, just set up a Personal
Web Server on your local machine, and you are there.
>
> How do you handle the problem with multiple running copies
> of the same program. Is there an easy way to get a unique ID
> for each running copy. (a dirty solution could be to use the
> machine address of a variable, but ...).
My solution was to incorporate into the file names and scripts
a unique character sequence containing BOTH the date/time stamp
and task ID of the programs. Both Windows and UNIX support this
approach. The date/time stamp gives you the number of seconds
(such as since midnight, Jan 1, 1970), and the task ID is a
separate unique number. My file and script names contain
strings that look like 98999645_12992 as a result, and each time
the data servers run, the values are different. BOTH values
were needed in case the same data server is run concurrently
(in which case, the date/time stamp will be the same, but the
task ID will be different) and there is a huge volume of traffic
(in which the task IDs may wrap around, causing two tasks to have
the same ID). There is still the off-chance that so many tasks
will be launched at the same time that we have a full task ID
wrap-around in a single second, but I don't think it is likely.
Rick
>
> Jacob
>
> ------------------------------------------------------------------
> ----------
> -- Jacob Sparre Andersen -- E-mail:
> [log in to unmask] --
> -- National Laboratory Risų -- Phone.: (+45) 46 77 51 23
> --
> -- Systems Analysis -- Fax...: (+45) 46 77 51 99
> --
> ------------------------------------------------------------------
> ----------
|