Multi-standalone communication

[Jesse Sng]

>I agree, AppleEvents are easier and faster than AppleScript.
>However, in my particular case, it was UDP I used.
>-1- I need both Win and Mac
>-2- the Rev 'do script' was broken until 2.7  When I was using 2.6   I could
>not be sure when this would be fixed and could not wait
>-3- the data service uses UDP to broadcast, not AppleEvents
>-4- low traffic rate for UDP is about 150 packets per second so that I do
>not have to worry about "not being able to receive fast enough", thus lost
>data is due to problems in my code

AppleEvents is managed by the OS and since it gets queued for you, 
you never have to worry about not being able to receive fast enough. 
Once your app is receive to process the next AE, it's there sitting 
in the queue.

One advantage over the data file approach is that you don't have to 
poll the file system regularly to see if there's something for you or 
not. Granted it eventually gets cached, but you still need to hit the 
file system (in memory) all the time.

With AE, you are now event driven and only need to respond when you 
receive such an event. Otherwise, your app is just sitting pretty.

>It would be cool if you could make some useful example stacks that would
>show 3 apps using AppleEvents.  I know Ken Ray has some good tips on his web
>site, which I have happily used.
>
>How would you use AppleEvents in your work flow?
>
>Jim Ault
>Las Vegas

In the past, I had 2 apps running on the system. This was an 
interactive kiosk app plus a controller app. The controller app was 
written in C++ and basically did most of the AE handling and the 
kiosk app had some rudimentary AE capabilities.

I had a 3rd app (sysadmin's app) running from across the network that 
would send AppleEvents to the remote machine's controller app. This 
app could then shut down the kiosk app, while it puts up a full 
screen that simply had a message saying that the system was currently 
"under maintenance". It had the ability to then automatically 
download the latest version of the kiosk app (signalled by the 
sysadmin), update its local copy of the database and even reboot the 
machine if need be. The controller app also did other things like 
managed log files and it receives log data from the kiosk app to 
track what users did on the system. I can't remember how the log 
files were transmitted, but I think it was through AppleEvents across 
the network to the sysadmin's app (it's been at least 8 years or 
more).

Once done, it would launch the kiosk app again. The kiosk app only 
needs to understand the "quit" AE, which is standard on the Mac and 
is sent everytime an app on OS X is required to quit itself.

So basically the sysadmin's app did most of the sending, the 
controller app simply received AEs and responded and the kiosk app 
mostly did what it was designed to do and in addition, responded to 
the Quit AE and sent log data via AE to the controller app.

Given the bandwidth limitations that I had back then (19.2kbps leased 
line modem connection bridging to a fibre network), it didn't make 
sense to use something like Timbuktu and I found this approach far 
more reliable.

All this worked very nicely considering that we were running on OS 
8.x without the kind of multitasking kernel that we have on OS X.

My original inspiration for all this was the concept of remote 
debuggers where data was exchanged between the app being debugged and 
the debugger. I had hacked up a remote debugger for one of my server 
apps so that I could monitor the status via AE and grab information 
and this eventually morphed into the controller app that I used for 
networked kiosk management.


Jesse