[MC_IDE] Quick Poll

Wilhelm Sanke sanke at hrz.uni-kassel.de
Wed Mar 30 14:52:39 CDT 2011


Richard wrote:

> On 3/29/11 11:24 AM, Wilhelm Sanke wrote:
> > > Could you possibly point out where we could find this "necessary info"
> > > from Oliver Canyon, if it was available it surely escaped me?. 
> This and
> > > the difficulties of Klaus - there are other reasons as I 
> understand and
> > > deplore on the side of Klaus - led me to assume that there 
> unfortunately
> > > had *not* been sufficient information from the RunRev side to build a
> > > new MC-compatible standalone builder
>
> In all fairness to RunRev, it's not an easy change.  And I would even go
> so far as to say it was a useful change, actually necessary as far as
> RevWeb is concerned and also UAC, and also helpful for both RunRev's
> license protection and for the MC IDE, since now the engine does all the
> bit-level stuff (binding the engine, embedding icons, embedding UAC
> info, etc.).
>
> It took a few back-and-forth emails with Oliver to get this down, and a
> fair bit of trial-and-error on my part.  Actually, a lot of trial and
> error since any error messages that come back from the engine are rather
> sparse.
>
> It's not a task I'd wish on anyone who has other things to do, but I do
> feel it's fair to say that RunRev, and particularly Kevin, Mark
> Waddingham and Oliver, made themselves available to help with my
> understanding of the initial example that Oliver had sent to Klaus and
> I, and ultimately it was their willingness to help that made the new SB
> possible.


and Klaus wrote:

> I received the neccessary infos from scotland but this is of course 
> nothing that should go into a public mailing list, so I did not 
> publish this info!

Thanks Richard and Klaus for the feedback, and also to Monte for chiming in.

Richard indeed makes it plausible that Kevin and his team still stick to 
their commitment to continue to help to support the MC IDE in its 
compatibility with newer engines of Revolution/Livecode.

Though - I say this with a piece of my tongue in cheek - the whole 
matter reminds me a bit of the "communication problem" political parties 
in Germany recently used as an argument when they had lost elections:

"We stand to our principles and our goals are OK, but unfortunately we 
had a communication problem with explaining our goals to the voters."--

Apparently the - somehow privileged - information received from RunRev 
was not comprehensive enough to let Richard and Klaus create a new 
standalone builder at once. Richard needed several contacts with more 
than one person and additionally trial and error processes as he writes.

And we had to wait one and a half year until finally we now got the 
prospect to see this new standalone builder soon.

I think such a kind of support from the RunRev side urgently needs to be 
improved and accelerated!

There is also the question - having been asked and discussed heatedly on 
the RunRev lists time and again - why are things sometimes made so 
overly complicated that they affect functionality and user-friendliness 
that negatively?

While overall it could be stated that Revolution/Livecode has indeed 
improved considerably over time, there are still features that are not 
up to par or have even deteriorated, among them the support for the MC 
IDE. Aditionally Revolution has had a lot of egregious problem issues 
during its development, think of one of the earlier application browsers 
that were practically unusable or the Rev standalone builder in 2004, 
which needed an hour or more to build standalones from certain types of 
stacks.

In my Teststack

<http://www.sanke.org/Software/RevTestStacks.zip>

I had described some of the problems encountered at that time and also 
outlined a recipe to fix this particular standalone problem.

At that time - 2004 - RunRev had also given up its principle to allow 
the possibility of total customization of the Rev IDE (a principle 
introduced and observed by Scott Raney for Metacard) by encrypting the 
standalone builder. Fortunately, there occurred a small time window to 
look at an inadvertently unencrypted update, which enabled me to make 
proposals how to fix the issue.
Shortly after this Monte Goulding was assigned to repair the standalone 
builder, which he did with great success - maybe using some of my 
recommendations (I do not know) or along his own lines - obvious to his 
analytical and practical mind.

Had we had access to the code of Rev standalone builder now, it would 
have been much easier for many of the Metacard group members to 
understand how the standalone file is being attached to a stack, and 
then create our own standalone builder accordingly.

I have never fully understood and accepted the protection of the Rev 
Standalone Builder. I know they give reasons pertaining to licensing  
procedures, and they want to prevent that someone circumvents the 
embedded licensing procedures and builds his own product and then 
competes with Revolution, but I believe these fears are unfounded, as 
there are surely means to guarantee a proper licensing process without 
necessarily encrypting the standalone builder.

Again, had the Rev standalone builder not been protected, its 
performance and structure would have been improved by now much more - 
and much faster - by interested and competent Revolution and Metacard 
users.--

I think, as the RunRev team still upholds a principal support of the MC 
IDE (like the German political parties I mentioned above), we should 
however appeal to Kevin to improve the support.

One other issue in this context would be to facilitate to embed new 
Livecode engines into the MC IDE and give exact directions how to so, 
and thus to avoid to force us to quite an amount of trail and error.--

And, would it be possible to get access to the privileged information 
Richard and Klaus received for creating the MC standalone builder? I 
would really like to know - and I think others, too - how the standalone 
file is being attached to a stack. And I assure sincerely that I am not 
intending to produce a competing product.

Best regards,

Wilhelm Sanke




More information about the metacard mailing list