ACGI Dispatcher - Does it still work?

BD--

It appears that the most recent date on the site is in 2003. And the Sentmans have a new daughter.

Hi, Anthony--

I put the compiled AppleScript application in

/Library/WebServer/CGI-Executables/env1.acgi

Then, using Terminal, I executed

chmod a+x /Library/WebServer/CGI-Executables/env1.acgi

acidispatcher is running (it's in the Startup list)

I pointed my browser at

http://localhost/cgi-bin/env1.acgi

and got the response

acgi services temporarily unavailable.

Just to check, I pointed my browser at

http://localhost/cgi-bin/env.cgi

(where there is a Perl script I had been working on)
and got the expected response.

There must be something I'm overlooking...

Thanks to both of you for your help.

--Gil

hope this is what you meant...

Get Info on the file acgi dispatcher.app in my Applications directory... Group is admin and access is Read Only

I noticed that there's a command in the File menu that says "Accept Connections". I selected it and the little monitor window changed. The "Refusing connections" line disappeared.

Then I tried pointing my browser and got a different response: a very long wait (Apple Event Timeout?) then:

An ACGI Dispatcher error has occurred

Unable to contact ACGI Dispatcher, AESend returns error.

Now that's progress!

The little monitor window now shows the count for today is 2 (reflecting my 2 tests, undoubtedly), and the Last Activity is a few minutes ago, so something's happening.

Thee isn't much documentation, just a few example scripts which sure look tantalizing if I can get them to work.

This paragraph was a little over my head:

For an OSX Server, Apache 2 or other non-standard install, click the
“Advanced” button in the install window and enter the path infor-
mation. acgi dispatcher requires a path to the user include direc-
tory of apache (the folder that apache walks through looking for
custom configuration files to load) and the cgi-bin directory.

I found a command to install/reinstall Apache configuration and it reproduced what I remember from the initial installation prompts.

The UNIX path to my cgi-bin directory is proposed as

/Library/WebServer/CGI-Executables

that looks right.

The UNIX path to my apache config user include folder is proposed as

/etc/httpd/users

I found there a file "acgi.conf" which contains

# This file is generated automatically by acgi dispatcher
# http://www.sentman.com/acgi/
#
Action acgi /cgi-bin/nph-acgihelper
AddHandler acgi .acgi

I looked in /Library/WebServer/CGI-Executables and was surprised to see -- sure enough -- a new file named nph-acgihelper lurking amidst my Perl homework cgis and the one Applescript example I had compiled.


It would be nice to hear that acgi dispatcher is working fine on somebody else's machine.

--Gil

I got it working.

Instead of compiling a sample acgi and placing the compiled result into CGI-Executables, I simply moved one to the folder. And it works.

So, the problem is in my compile step, which I'll probably be able to figure out.

So, acgidispatcher works. Thanks for your help.

--Gil

12 inch PB G4 w/20 inch Flat Plane Array Mac OS X (10.4.9)

You asked...

The script has to be compiled as a "Stay-Open" application", which means that once it's launched it never quits. The same condition applied in OS9, so it wasn't too hard to figure out. A mention in the documentation would have been nice.

Applescript modules (called scripts) are not plain text files, but must be created by a special editor ("Script Editor.app" is one.) When the file is Saved, options allow the file to be saved as an application. This one file then functions as an application but also contains both source and object. When you launch the file, the application runs. If instead you opened the same file with the editor, you could edit the source and Save again.

Scripts typically are coded in a single file with a program at the top followed by all its subroutines. The top program is called the "run" handler because it is run whenever the application is launched.

Subroutines are called "handlers" because they can be accessed externally, from other scripts, even other processes. There is syntax to call a handler as a subroutine from the run handler or any other handler in the script. There is also syntax to call a handler defined in another application:

tell application "foo" to dowhatwith given params

You can even make the top-level program in another application run again:

tell application "foo" to run

The name of the handler and the syntax for its parameters would be defined in the other script:

source in file "foo":

<... run handler code here>
on dowhatwith given params
<..."dowhatwith" handler code goes here>
end dowhatwith

For these sample acgi applications, the run handler is null: when you launch them they do nothing. However, they all have (at least) one handler named "handle CGI request".

on handle CGI request
<...>
end handle CGI request

This is the entry point for Apache or MacHTTP or WebStar or whatever http server is calling the AppleScript cgi.

Apache will first launch the application then call the "handle CGI request" handler. Problem is, the application will finish its run handler and quit almost instantly, so then there's no process to handle the "handle CGI request".

The solution is to make the AppleScript "stay-open" when saved, so that once launched it never quits. And there they are in my dock right now, still running after my tests yesterday. I can quit them manually.

I like to code my cgi scripts so that they do quit by themselves after a few minutes with no work. This is assisted by a special "idle" handler which, if present in the script, MacOS will call with no parameters every now and then.

So I'm off and running on this path for now, to see where it leads.

Thank you very much, Anthony, for your help and encouragement, and especially for your review of some very attractive alternatives.

--Gil



12 inch PB G4 w/20 inch Flat Plane Array Mac OS X (10.4.9)