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
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
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
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?
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.
metacard mailing list