mission critical apps; was Re: cross platform ide

[Frank Leahy]

On Monday, February 9, 2004, at 10:35  AM, 
use-revolution-request at lists.runrev.com wrote:

>
> What is the argument against the xTalk messaging model?
>

Richard,

In most any other dev environment, the only "messages" your app gets 
are mouse and keyboard events, and possibly network events/messages -- 
otherwise you are in control of everything else, from what gets drawn 
on the screen to what user interaction occurs.  If there's a bug, 
there's a good (better) chance it's your problem, and you can usually 
track it down (modulo problems with whatever framework you might be 
using).

In RR though, everything's a message, and every piece of code is 
written in response to literally hundreds of different messages.  And 
this fact that you're one step removed from the actual user means that 
it's incumbent on RR to ensure that the messages it passes are correct 
and complete, and in the right context.

That said, I can think of at least four problems that I've seen with 
the messaging model (which I happen to like by the way):

1) There is no convention for whether one needs to pass messages up to 
the system.  For example,

on openCard
    ...do my stuff...
    pass openCard
end openCard

What impact, if any does passing or not passing openCard (or any other 
message) to the system have?

2) It's hard to guarantee the message passing context.

on someCommonFunction
    send "foo" to this stack
end someCommonFunction

Sometimes the only way to guarantee that this gets sent to the right 
stack is to make sure the "this" stack is physically frontmost.

3) The messaging model does not always work correctly.  And it 
sometimes works differently depending on where the code resides.

For example, correctness: I've been adding drag and drop to my app, and 
very often neither dragEnd nor dragLeave are called.  It's probably a 
bug, but it isn't the only messaging bug I've seen.

As for "works differently": "on drag..." handlers work differently if 
they're in a control script vs a card script vs a stack script.  That 
shouldn't be the case.

4) Race conditions.

I've seen cases where multiple "dragMove" messages get fired before my 
"dragEnter" handler completes.  This caused all sorts of havoc with my 
code.  And without a semaphore mechanism built-in to the language it's 
impossible to know if I've solved the problem, or whether it will crop 
up again on a faster or different machine.

Best,
-- Frank