license issues (was mystery exception)

[Robert Brenstein]

>Now think about this for a minute. If your standalone were unlocked, 
>yes, someone might create a competing IDE. But even if they just 
>used your standalone to create their own software, that is one less 
>copy that Runtime would sell. You and I, as developers, are staking 
>our future on this technology. We should *want* Runtime to guard 
>their product, sell lots of copies, and have a huge customer base so 
>they will survive to be there for us. Why would anyone pay for a 
>developer copy when any old standalone with a message box was fully 
>functional?
>
>The script limitation is the one, single, sole, solitary, and only 
>protection that Runtime has.

All true but how easy is it to use the engine of a standalone to 
couple it with full development GUI to produce new products? Is 
message box really fully functional in standalones? If so, I rather 
have no message box than do limit. I also think that while 
distributing an unlocked engine could lead to problems you describe, 
it should be possible to couple the engine to a specific standalone, 
for example by requiring the stacks in the standalone to pass the 
license key with certain calls. Such an approach would allow us to 
realize the unfullfilled promise of being able to distribute any! 
MC/Rev-based standalone without it being crippled by this restriction.

And I agree with Alex that this should be clearly spelled out. I have 
actually found about this restriction when producing a test version 
of a standalone program (see below) -- after I paid for the license. 
I was quite upset. Fortunately, that specific program was not the 
only reason for me to buy the dev environment.

>There's also the issue of abstract versus reality. In the 16 or more 
>years in which I have been writing x-talk scripts, I can honestly 
>say I have never once needed an 11-line "value" function. I can't 
>imagine the convoluted script that would require something like 
>that. I can't even imagine a script where the syntax would work out. 
>I suppose someone might want to plop a whole field's worth of script 
>into a "do" command, but not only is that rarely necessary, there 
>are ways to break the code up if it really is required. Only it 
>hardly ever is. I've never needed a "do" statement that long.
>
>In practice, I think you will find the script limitation to be a 
>completely minor inconvenience, worthy of almost no consideration at 
>all, except as a great big chunk of insurance against the future for 
>all of us.

Well, this may be true for most people but it can be a show stopper 
for some. Consider a scientific application that involves modelling 
or function fitting. I have written such a program some years ago 
(sold as shareware) and would love to recreate it with MC/Rev (users 
still ask for it but the old code stopped working with OS 8). It 
requires users entering complex math functions that program matches 
to the provided set of experimental data, calculating statistical fit 
and producing graphical output. It would be trivial to run it through 
"do", but the 10-line limit is a killer. The only alternative I see 
is to write my own interpreter/compiler in MetaTalk but that ain't so 
trivial and slows things down. Of course, another alternative is to 
have each user buy their own copy of MC or Rev but that would be akin 
to asking users of programs written in C to buy CodeWarrior (although 
I am sure that MC/Rev folks would love it).

Robert Brenstein