Thanks for the info, Mike. I had the same problem with trying to do =
console I/O (to a non-existent console) and just blindly followed your =
example to work around it. Having output, such as startup status, in a =
log file turned out to be quite useful.=20

I have used text file I/O to solve a number of problems I encounterd =
while developing Server-based (assisted?) applications.

It sounds like Franc's database must be memory-resident for performance. =
 I had a somewhat similar problem: I needed to access a database managed =
by another SwiftForth program -- this program runs continuously and has =
all of the typical search/sort/formatting capabilities. I solved the =
problem of accessing this database by having the HTTP Clients request =
the program to search, format and output reports as text files. I use =
Mike's Server to render the text report in HTML for remote user display =
via a browser. Users can view and print the report, using a browser, =
from any PC on our network. Thus, the HTTP clients did not have to =
directly access the database owned by the other application but could =
ask it to do search and generate text-file output.

I am not sure that this approach would work well with ad-hoc queries or =
the large files that Franc mentions, but the idea of passing parameters =
to a resident database application may simplify things if user queries =
can be anticipated. =20

I have found that using a Unix-like model, with inter-program =
communication and configuration via text files, is very useful. =
Writing, reading and rendering text files with Mike's HTTP Server is =
very straightforward. An added benefit is that definitions for these =
can be compiled into the Server dictionary at startup, thus conserving =
dictionary space in the spawned clients.

I am surprised that I have seen only a few SF Talk queries related to =
Mike's server. I have found that using his server to remotely interact =
with SwiftForth applications and clients is an easy way to provide =
password-protected remote user access, especially for applications that =
require "looky loo" browsing and local print capability.

-----Original Message-----
From: Mike Ghan [mailto:MikeGhan_at_logix-controls.com]
Sent: Thursday, February 17, 2005 8:17 AM
To: SwiftForth Talk (SwiftForth Talk)
Subject: [sftalk] Re: SwiftForth WebServer - question

Hi Franc,

The variable TRANSACTION# is defined in the example Custom.F. The
example script TEST.FS (which is accessed as http://localhost/Test.shtml
) references that variable. You'll see it's value on the rendered page
just above the table at the bottom (ex "Time is 07:22:45 Transaction#
5"). This demonstrates that global (i.e. none transient) data can be
accessed and modified by a client session.

I did find one annoyance: When starting the server and compiling
Custom.F, any output which would normally be displayed to the console
will cause a fault. If Custom.F contained the phrase .( I'm Compiling)
for example, the server would abort. The problem is that the SwiftForth
console does not exist (and must not exist to satisfy the licensing
requirements). The fix is quite simple; place the following near the
top of Custom.F:

>FILE Compile.Log

This will redirect any compile time output to the file "Compile.Log".

Hope this helps,
Mike

-----Original Message-----
From: Franc Vodopivec [mailto:fvodo64_at_hotmail.com]=3D20
Sent: Wednesday, February 16, 2005 2:36 PM
To: Mike Ghan
Subject: SwiftForth WebServer - question

Hello Mike.

I am sending this to you directly because I don't know if this would be
of general interest to the group.

I bought SwiftForth and am working on a "real" project. The project
consists of parsing a number of 5 to 300 MB files that contain
specifications and logic for various database applications for the
purposes of having oon-line inquiries for documentation purposes (what
programs use this field/file?). I would like to use your webserver to do
this however I can't access any memory that is in the "custom.f" area
(which is where I put the parsed info). The parsed docs take between 1
and 10 MB of Forth dictionary space.=3D20
If I put the specs into a database it will slow down by a few orders of
magnitude. If I put the parser in the scripts it will be too slow as
well and will parse on EVERY hit. In a perfect world I would like to
parse a system in the "custom.f" section and then have access to its
variables (files, fields, logic) from the script side. Do you have any
solutions for this problem?

Thank you for your time and thanks for the webserver

Regards,

Franc Vodopivec

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug=20
reports, please send email to support_at_forth.com
----------------------------------------------------------------------

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Thu Feb 17 2005 - 10:18:50 PST