Second thoughts

Wilhelm Sanke sanke at hrz.uni-kassel.de
Sun Apr 3 12:20:33 CDT 2011


After Jacqueline had helped me to understand the basic constellation of 
the interplay between engine and standalone builder to secure the 
license binding by encryption, it occurred to me that there is still the 
question which parts of the standalone builder really must to be 
encrypted to achieve that goal.

The Rev standalone builder is a multi-purpose animal, attaching all 
kinds of stacks and libraries and also removing all kinds of garbage put 
in by the Rev IDE, but not needed for the standalone. Especially these 
processes and when they had been scripted inadequately - which was the 
case rather often - caused the difficulties for building standalones 
from certain types of stacks (with build times of more than an hour etc.).

These parts of the standalone builder need not and should not be 
encrypted, only the very small part where the license binding takes place.

Looking through the archives (the present "Livecode-dev" archives, 
formerly the "improve-revolution" archives) I came across a post from 
Richard (Nov 11, 2003) in response to one of my messages about "Building 
standalones of larger stacks". Interestingly, Richard here presents 
arguments for an *unencrypted* standalone builder - "Distro Builder" at 
that time - when he says "locking......prevents real and sometimes 
critical problems from being addressed more quickly".

This statement is exactly in the line of arguments I presented in our 
recent discussion in thread "[MC_IDE] Quick Poll".

Here is the text of Richard's historic message from the Livecode-dev 
archives:

> ================================
> Building standalones of larger stacks
> Richard Gaskin ambassador at fourthworld.com
> Tue Nov 11 11:41:22 CST 2003
>
>    Wilhelm Sanke wrote:
>
> > As I have stated earlier in this thread, "We would need to compare size,
> > number of controls and probably other structural elements of a stack to
> > find out why the Rev IDE is so very slow in some constellations, and
> > then find out  how to remedy this."
> >
> > And indeed the Distribution Builder needs 43 minutes for my 10 MB stack
> > - I am repeating myself here -  (and only 3 seconds in the Metacard
> > IDE), so <3 seconds for your rather small 116 K stack does not
> > contradict that.
>
> It's too bad Rev's Distribution Builder is locked up.  If it were as 
> open as
> MetaCard's we could compare the scripts, fix the issue, and deliver it to
> RunRev, as we have with MC annoyances in the past.
>
> I can appreciate the reasoning behind locking it up, but MetaCard's 
> long and
> profitable history suggests that locking it may be a solution in 
> search of a
> problem, sadly one that prevents real and sometimes critical problems from
> being addressed more quickly.
>
> Should unlocking the Distro Builder be an enhancement request?
>
> -- 
>  Richard Gaskin
>  Fourth World Media Corporation
> ==================================


I think the consequences of these insights could be:

- Richard should as far as possible leave the new MC standalone builder 
unencrypted, save for the tiny part of the license binding.

- Richard could renew his intended enhancement request from 2003 and ask 
Kevin to create the next Livecode standalone builder along the same lines.

And more, if we could persuade Kevin to facilitate the process of 
putting new Livecode engines into the MC IDE , this would in effect 
indeed turn out as a "win-win-win-situation" - a triple gain for the 
Livecode team, for MC IDE users, and for Livecode users.

Irrespective of the legal and other terms laid down at the time of the 
acquisition of the Metacard engine by Kevin, such improvements would 
surely enhance trust and the motivation to continue to actively support 
the further development of Livecode.

Best regards,

Wilhelm Sanke



More information about the metacard mailing list