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
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

metacard mailing list

Reply via email to