mission critical apps; was Re: cross platform ide
frank at backtalk.com
Mon Feb 9 05:16:04 CST 2004
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?
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
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,
...do my stuff...
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.
send "foo" to this stack
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.
More information about the use-livecode