Multi-standalone communication

[Jim Ault]

On 12/8/06 10:38 PM, "Kay C Lan" <lan.kc.macmail at gmail.com> wrote:

> OK, I'm a hobbyist I'll stick my head out, but all the solutions here seem
> to be overly complex for what appears to only require local processing at
> the speed of button clicking. I use a method that is easy and seems to be
> overlooked.
> 
> I regularly send large amounts of data between 2 Standalones, you can:
> 
> set the myCustomProp of stack "Standalone No 2" to tMyLargeAmountData
> -- if you just want the data to be available in Stack 2 for later use. If
> you want to start a process and send data to another stack it's pretty
> simple to:
> 
> send hHandlerInAnotherStack tMyLargeAmountData to stack "Standalone 2"

The original question related to a CGI solution and that Rev is not
multi-threaded.  Of particular concern is the number of hits a server can
receive in the same few seconds (web or database) which would mean a single
CGI app would be busy handling the first ping and not be able to keep up
with multi-user environments or data query intense apps connecting to the
CGI.

Later in the thread, it became 2 or 3 apps on the same Windows computer.

My required system is one of many tasks that need split-second timimg, thus
UDP works well.  In the past I used Applescript, text file writing, and even
writing to an ftp folder/reading from that folder [in fact we still use 5%
of that]. 

Another aspect of the UDP socket is that packets can be received and queued
and performed(!) while I am stopping/debugging another script *in the same
app* *in the same container*.   That's right.  I can step through variable
watcher to see the data conversion repeat loop errors in one handler while
the "gotNewPacket" handler gets triggered and stores the new data.  I can
then edit the handler I am in, apply, and everything keeps working.  I mean,
holy cow, I can test and recode my handlers on-the-fly!!

Without this ability in Rev, my networking would still be on the workbench
for repairs and debugging.

The Rev message path keeps working so you can change the tires while your
network is processing messages.

Certainly this is above the hobbyist level, but is critical to my business
venture, and would be an area of interest for CGI.  Additionally I need apps
running on different computers on different networks, so 'send' does not
work.

Glad you found and explored an easy 'send' method.
I did not know that you could simply 'send' between two standalones.
Does this really work on both Mac and Windows? or just Mac?
Do you have any examples?
My definition:  Main stack >saved as > standalone.app or  standalone.exe

If all of my stacks could be in the same app on the same computer, life
would be simple.

Jim Ault
Las Vegas

------------ Original email  ------------------------------------------
> OK, I'm a hobbyist I'll stick my head out, but all the solutions here seem
> to be overly complex for what appears to only require local processing at
> the speed of button clicking. I use a method that is easy and seems to be
> overlooked.
> 
> I regularly send large amounts of data between 2 Standalones, you can:
> 
> set the myCustomProp of stack "Standalone No 2" to tMyLargeAmountData
> -- if you just want the data to be available in Stack 2 for later use. If
> you want to start a process and send data to another stack it's pretty
> simple to:
> 
> send hHandlerInAnotherStack tMyLargeAmountData to stack "Standalone 2"
> 
> I only do this between two stacks, so specifying 'to stack "ABC" or 'to
> stack "DEF" is pretty easy, but I imagine that if you were working with 4 or
> 5 standalones it might be simpler to create a library stack, of which all 5
> use, and then include 3 parameters with your handlers, the long Name of
> the Originating object, the long Name of the Destination object, the data
> 
> The only problem with this is possible queuing conflicts. I don't know what
> will happen. In my case I click a button in Standalone 1 and in the
> background something happens in Standalone 2. If I go to Standalone 2 I can
> do things that change things in Standalone 1. If I click in Standalone 1 to
> start the process in Standalone 2, and then immediately go to Standalone 2
> and it hasn't finished processing then I get the usual busy cursor. I can
> either click back to Standalone 1 and do something whilst Standalone 2 is
> crunching away or I can stay in Standalone 2 and wait for it to finish, then
> proceed.
> 
> What I don't know is if you have 5 Standalones, and you click in Standalone
> 1 and it starts a process in Standalone 2 which runs a process in 3, which
> runs a process in 4, which runs a process in 5 which sends a message back to
> 1. If 1 is idle, it will be activated and everything will work. But if you
> commenced a Standalone 1 process and it is 'busy' and Standalone 5 sends a
> message to 1, I don't know if the queued message will be handled correctly.
> Actually I'm sure a couple of queued messages would be correctly dealt with,
> it is whether you have 100s of messages from different Standalones all
> queued whether they'll be handled correctly.
> 
> I guess that's why everyone else has come up with more complex options, but
> depending on your needs, 'of stack "ABC" ' and 'send' maybe all you need:-)
> In my case I'm certainly no 'clicker at the speed of an sms sending
> teenager', so there is plenty of idle time in Standalone1 to catch 'send'
> from Standalone 2 and vica versa.
> 
> I'm sure those in the know will tell me what other 'gotchas' exist with this
> method:-)