Apache Apple Event Bridge

[hodger]

(posted yesterday to the list, and now here as well...)

Hi List buddies,

A few days ago David Dantowitz released his "Apache Apple Event Bridge" solution, which enables Apache to send CGI requests to appleEvent aware applications like SuperCard. Previously the only viable solution for Intel/Apache integration was ACGI-Dispatcher, which has been largely ignored by the developer for a number of years and only supported a small subset of the environment variables available.

I have only been testing the aaebridge for a day, but have already found it to be an excellent solution for standard forms processing and text/html response data. Cookie support seems to work well, and there are some environment variables now that were unavailable to SuperCard and FlameThrower under Classic webservers.

CGI responses that generate image/jpeg data do not seem to work at this point but I am exchanging e-mails with the developer to see what can be done to ensure compatibility with SuperCard's capabilities to generate image data directly into variables.

Within a few weeks I will also post an updated FlameTwo package that works seamlessly with AAEB.

Greg

Apache Apple Event Bridge
http://www.aaeb.net/

FlameTwo
http://homepage.mac.com/hodger/FlameTwo/

[KelleherD]

That's great Greg. Thank you very much for staying with this and giving us the news.
-Dan

[Dave Higgins]

I've been using a different approach for something that I've been cooking up for a while (but have neglected lately as I delve into Obj-C and AppleScript Obj-C).

Instead of using AppleEvents, I wrote a little shell script bridge that spools the incoming data into a temp file inside a folder that SC polls looking for anything new. When found, it reads the file (which contains the headers and the post data), then my app processes it and writes the reply HTML to another temp file.

I'm currently working up my own AppleEvent bridge (funny because I was just starting on it as I read your post) to see how it might work in comparison, but it's going slow as I'm just learning pure Obj-C and spending about 95% of the time looking up "how to" sites on the basics.

I read in his docs what some of the AppleScript classes are for the event params, and I may try to match them, but to start I think I'm just going to wrap up the whole thing in one event and parse it out in SC the same way that I am when reading in these files.

CGI responses that generate image/jpeg data do not seem to work at this point but I am exchanging e-mails with the developer to see what can be done to ensure compatibility with SuperCard's capabilities to generate image data directly into variables.

I wonder if this has to do with going through an AEs, or because he's handling data with C (running into null trouble with binary data) instead of Obj-C, or what. IIRC I've had no trouble sending back images with image/xxx Content-Types, but I'm including it in the reply string that gets passed back to the bridge (via the file).

It looks like my AppleEvent Obj-C bridge I'm working on should be able to handle the raw data just fine, but I'll know more when I get to actually tossing the AEs around.

Anyway, maybe someday when I grow up I'll clean up the visual mess that is my project and you can have a look at that. I think you and I are both creating some of the same wheels here as I've written a zillion wrapper functions and handlers that try to match up with (and include even more than) Flamethrower. I've been working on other stuff with it, too, like site/host/domain management, DNS management, Apache installs management, etc... That's a big part of why it's not been shown off yet.

Setup on mine seems to be less messy. No need to make scripts, copy apps into the bin, give special names, place an empty text file, etc... Only requirement is that you have one special project userprop with the short name of the cgi that you want it to handle (mytest.cgi). No URL like .../cgi-bin/AppleScript.app.aaeb or any of that.

[DavidDantowitz]

Never played with returning binary data, but just added that so you can return a JPEG or other binary data. Version 1.3.1 will be available in a day or so.

Also, the app is set up to handle sending CGI Requests to an app. Since compiled AppleScripts on 10.6 are always bundled apps Apache doesn't like calling them directly -- they look like a folder.

For security reasons, you may not want apps running just anywhere on your machine (as Apache enables other machines to access your machine), thus limiting CGIs (as Apache does do start) to one folder or folders you explicitly indicate in the Apache config is a good thing. You can override it to use any folder you choose.

There are many ways to connect apps. This is just one. It's fast as it avoids the file system (creating a file) or using pipes, etc. The Mach messages underlying Apple Events seems quite fast. Also, by avoiding interaction with the shell or file system, you avoid some avenues to break ins. Nothing's perfect, of course.

The original need for the app for me was to connect to a custom database (nothing to do with AppleScripts). So you can connect directly to any app, not just compiled scripts. After getting it to work with my database app, I started looking into a more general solution. Some thought went into the limitations and ease of use issues. Some people feel enabling AppleScripts is a security issue. But, you can write shell scripts too (or have someone copy them into your system).

So, I look at the need to have an extra text file as an extra security thing. I could have added code signing with a symmetric key, or having a file that lists scripts permitted to be called, and so on.

Any suggestions are welcome. Software is soft, so any changes are possible Given that you have a bundled app when you compile a script, you can't trigger it directly via Apache right now without modifying Apache -- and remember, this is a simple addition to Apache -- nothing to recompile, nothing strange to configure, etc.

So, by adding a handler for a file extension (.aaeb) you can have Apache call your code via AAEB. Easy enough for anyone who dabbles in AppleScripts. The goal is to run AppleScript in as natural a form as possible, with elegance.

Here, the URL directly refers to the script by name:

YourServer.com/cgi-bin/AppleScript.app.aaeb?args=test

Another way to go would be to have something like:

YourServer.com/cgi-bin/runScript.aaeb?runScript=AppleScript.app&args=test

This removes the need for the extra Text file, but seems less elegant. I guess you could add a URL rewrite rule to handle this automatically too, even getting rid of the need for the text file. I'll look into that. Still would require a little more complex installation for the update to the Apache config.

Anyone like this? Let me know, I can add it to the 1.3.1 release... like the web site says: Custom Software -- any ideas or feature requests, let me know.

David Dantowitz

[KelleherD]

Thank you David.

[DavidDantowitz]

Version 1.4 is now available.

Supports returning binary objects and has a new connection mechanism, so you can now call a compiled script via:

YourServer/cgi-bin/connect.aaeb?appName=CompiledScript.app

Of course there are any number of ways to use the Apache rewrite module as well.

Check out the new video at:

http://aaeb.net/

David

[hodger]

Hi David,

Thanks for solving the binary data problem. I just ran a quick test for jpeg's and bmp's with no problems.

Greg

[hodger]

... I wrote a little shell script bridge that spools the incoming data into a temp file inside a folder that SC polls looking for anything new. When found, it reads the file (which contains the headers and the post data), then my app processes it and writes the reply HTML to another temp file. ...

Hi Dave,

I am quite interested to understand your concept a little better. I started a new topic "Triggering SC from shell scripts" in the SuperCard Basics section (doesn't seem to be a better option.) Can you share how your SuperCard project polls for new things and also how your SuperCard project pushes the response back to the right place?

Thanks,
Greg