REM> I don't quite understand why you need to do anything like that.
REM> To set up a CGI program, you either have the application directly
REM> as a script in the CGI file (typical way to do it in sh or perl),
REM> or the application directly machine-executable (C, C++), or you set
REM> up a sh script which launches the actual application (lisp, java).
REM> Auto-loading of modules in lisp or java is part of the mechanism of
REM> the language itself, having nothing to do with CGI. You just need
REM> to make sure the classpath is correct in java, and that you have
REM> autoload stubs in lisp.
> From: "WALLYWORLD" <ran...@[EMAIL PROTECTED]
>
> How can I do anything you mention with Windows...?
I can't answer that specifically, because I've never had access to
any MicroSoft Windows system which is CGI-accessible from the
network. Presumably there's something like a public_html directory
with a cgi_bin sub-directory, although the names may be different
on MS-Windows compared to Unix/Linux.
Google search for: cgi windows xp
<http://www.cgi101.com/learn/connect/winxp.html#8>
#!/perl/bin/perl -wT
print "Content-type: text/html\n\n";
print "<h2>Hello, World!</h2>\n";
... put "first.cgi" as the file name. Save it in your My Website folder,
...
Since I have no access to any MS-Windows system here, I have no way
to verify it works. Would you please give it a try?
If that's correct, it took me only 5 minutes to find that info and
aother 5 to copy&paste the relevant tidbits into this message. Why
couldn't you find that info yourself, instead of pretending that
you had no way to learn that except by asking me?
If that's not correct, if My Website isn't the right place to put
CGI scripts, then maybe somebody with experience with CGI on
MS-Windows can provide a correction now that I've given a good
guess?
> Further down in this page, "The Web browser serves as the
> Universal client and must be able to access and display data from
> virtually anywhere. Unix-based and NT systems have an edge as a
> data source, because they sup****t intranet standards.
Yeah, so what?
> However mainframes and midrange computers are not as fortunate.
> Not only do you have to convert working networking protocols, you
> must also concern yourself with different text standards (ASCII and
> EBSDIC)
Don't you even know how to spell "EBCDIC" (Extended
BinaryCodedDecimal Interchange Code)? When you copy text from some
other source, don't you even notice when a key term is misspelled?
AFAIK, except for some IBM mainframes, virtually all the mainframes
and midrange computers used ASCII.
> and the nuances of terminal based communication.
The DEC PDP-10 (and earlier PDP-6) did terminal based communication
just fine. The only IBM mainframe system that I recall had trouble
with decent terminal based communication was Wylbur, which was
based on an explicit half-duplex protocol with the keyboard
**locked** whenever it was not the terminal's turn to talk. It was
actually painful to try to type when the keys on the IBM Selectric
terminal were physically **locked** and refused to budge when the
fingers tried to move, causing servely stubbed fingers that made
them sore for many minutes afterward.
Except for that one rather obsolete example (is Wylbur even
installed anywhere nowadays?), can you cite any mainframe that
couldn't do decent terminal/modem I/O?
> One way of handling this problem is straight forward: You convert
> terminal based forms into Web pages, creating CGI fields mimicking
> the source screen.
I'm missing the connection here. What does difficulty of some
operating system doing user-friendly terminal I/O have to do with
the problem of applictions designed for local IBM 2250 screens
being converted to use Web forms instead? (I might have the IBM
product number wrong. It might be 2235 or somesuch.)
Any decent software application is written in such a way that
specific parts of the software deal with setting up forms on the
screen and accepting user interactions from it. If these parts
aren't neatly modularized, then the program needs to be refactored
to provide cleanly separate modules for user-interface vs. data
model and business logic. Once this is done properly, it's possible
to generate alternate user interfaces for each of:
- Web forms
- stdio command loop
- GUI (awt, swing, clim, turtle-graphics, HyperCard, VB, etc.)
- text screens (VT100, IBM2250, TheComputerForPeopleWhoLoveMoney)
such that exactly the same data model and business logic would work
in any of those modes.
> This process is often called wrapping (or screen wrapping),
> because you are simply adding a translation layer between the
> terminal based application and the Web-based application.
Somehow I don't think that's a good idea, trying to emulate one UI
using another existing UI, by guessing the intentions of the base
UI. Better to abstract out what is *really* wanted at an abstracte
level, and implement the various UIs in parallel. It takes more
work to refactor the UI to modularize it out, but I think that's
really necessary to make the application work at all.
One essential difference between the various kinds of UI is that
Web forms are tied to an explicit full-form transaction whereas
other modes allow more incremental operations. There's just no way
an application that already assumes incremental screen operations
can be used in a Web-form environment simply by adding an extra
layer between the Web and the old application.
One thing that seriously doesn't work in Web forms is
drag-and-drop. But multi-selection of objects followed by selecting
what to do with the group seems to me an entirely satisfactory
work-around that is compatible with Web forms. (In fact
drag-and-drop is rather user unfriendy at times where your finger
slips off the mouse button at the wrong time and suddenly your
group of ten icons are dropped into some wrong place, such as into
a folder you are accidently over. Sometimes I wish I could select a
group of icons, and select the target, separately, and *then*
confirm that's where I really want then to go, instead of they *go*
already the moment I accidently lift my finger off the mouse
button. Same with pull-down menus. The pre-2004 Yahoo! Mail
interface has me select checkboxes of messages I want to move, and
pull down a menu to select which folder to move them into, and then
I have a chance to visually check if I got the right destination
before I click the MOVE button. The 2004-current interface uses
JavaScript to **immediately** move the messages the moment my
finger lifts from mouse button while pulling down the desination
menu, which is a royal danger which has bitten me several times.)
> Although I only have use UNIX in a programming mode, with a C
> compiler, the UNIX systems have do***entation that is worse than
> even Windows systems.
I'm not aware that MS-Windows has *any* decent do***entation to
begin with. But in either case, you need to know the name of the
application before you can ask how to use it. If you have a task in
mind, but don't know which application might do it, it can be very
difficult to find any useful help. For example, on the Macintosh if
you want to collect the entire screen view as an image file (which
you can then im****t into MacPaint or into HyperCard or install as
your desktop background), you just press a clover-number
combination which is well do***ented in the printed do***entation.
But on Windows, the same task is not do***ented anywhere I could
find, and the person in charge of our semi-public computer center
had not the slightest idea how to do it. Finally at Grace Community
Center in San Jose I by chance found somebody who knew the crucial
first step and had an idea for the second step and by experimenting
I finally found a series of steps using one keystroke plus three
separate application programs that could finally create a picture
file of what the screen looked like.
(I've never had GUI access to a Unix system, so the question never
came up on such. I haven't investigated how to do such a task on
my RedHat Linux laptop.)
> It seems to me that it gets worse until you to give up on Unix
altogether,
That doesn't parse. Is there a word missing? Or an extra misplaced word?
> It would most likely be impossible to achieve a UNIX server which
> is secure, and write even a mickey mouse application to run on
> it, without employing a dozen people for at least 5 years.
But secure Unix servers already exist, so why re-invent the wheel??
> I doubt if I know how to create terminal based forms into Web pages.
That isn't English. Is this what you meant to say?
< I don't know how to converte terminal based forms into Web pages.
So what exactly do you mean by "terminal based forms"?
Do you mean command loops where you have a prompt asking for some
command of some particular type, with brief list of valid commands
available, and you type ? for a verbose list of commands?
Command (F, U, P) ?
F = Browse for a file
U = Type a URL
P = Start a program
Command (F, U, P) F
Name of file: tmp*.txt
Select one of these files:
1 = tmp1.txt
2 = tmpfoo.txt
3 = tmpbar.txt
Q = quit back to main command
Select: 2
Selected tmpfoo.txt, what to do with it (D, R, V) ?
D = delete
R = rename
V = view in text editor
Selected tmpfoo.txt, what to do with it (D, R, V) R
Rename tmpfoo.txt to: newJob.txt
Successful rename.
Command (F, U, P)
Or do you mean some sort of full-screen-text-mode form, using VT100
or other termcap (used by lynx, emacs, vi, pine, etc.), or IBM2250
(used by various VM/CMS utilities such as dir, mail, etc.), etc.?
> The article I was citing - Web Publi****ng Unleashed (i think)
> suggested that converting Windows Word do***ents into Web pages was
> elementary work.
Well, you open the File menu, select Save As ..., at the bottom of
the dialog where it says type of file to save you change it to Web
Page, then click the OK button, and it creates a main HTML file
plus a sub-directory containing all the images and other non-text
components. Didn't you know that? Or are you talking about
something else?
(Snipped the rest of your ramblings...)
|
