On Wed, 30 Mar 2011, Richard Gaskin wrote:

Blame me for that, not RunRev.



I wasn't intending to blame you or any other member of this list - and I indeed assess it as honorable that you try to find reasons why this situation has developed as it is now and thus defend RunRev.


MC is an open source project outside of RunRev's role. It's not theirs to maintain, it's ours.


Of course, I fully agree. We do our own maintenance and I have contributed to it, as you know. But it is another matter when that maintenance is made more difficult because of new features (for that matter new engines and standalone builders) that are extremely troublesome to integrate.

What would you like to contribute?


I am not sure if I understand your question. Contribute to the MC IDE, or to Revolution/Livecode?

For those afflicted by a short term memory I could draw up a lengthy list, but there is another way: Just search the archives of the RunRev lists and also the bug reports.

Just to pick out one point:
Presently I am working in a cooperative project for integrating embedded Lua into Livecode, which will speed up image-processing by a factor of 100 or more. Kevin has already invited us to write a RunRev newsletter article about that when we are ready.

Another example: Here is part of a recent message from Jim Ault (of March, 25), and you can watch the videostream from the URL below:

Last Saturday I did a volunteer presentation for the Live Livecode Code group that featured your stack Seamless Tiles Generator 2 One of my goals was to let more people know about your outstanding work with image data and conversions.

There is a 50 minute recording of this on UStream.
Jim Ault
Las Vegas

-------------------------
message from     m.schonewi...@economy-x-talk.com

You can watch Jim's presentation here:
<http://www.ustream.tv/recorded/13430477>


You can download the "Seamless Tiles Generator" from here
:
<http://blog.livecode.tv/wp-content/uploads/2011/03/SeamlessTiles2.zip>

or there

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

which is meanwhile a stack four years old.

================

Back to the quotes from Richard's post:

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.


Right, but as I noted earlier they've since fixed this by moving the build process into the engine.


When they have now moved the build process into the engine, why is the standalone builder still encrypted?

I've seen nothing worse than disinterest from RunRev with regard to MC, and often some very direct support of our effort even though it has almost nothing to do with their business plan. Never have I seen any indication of any attempt to thwart MC.


You may be right, it may be just "disinterest" in a negligible minority, not a purposeful attempt to thwart MC. But the actual outcome of this attitude are the difficulties we presently encounter. I think commitments should be observed no matter whether they affect a minority or not.


I have never fully understood and accepted the protection of the Rev
    Standalone Builder. (snip)
but I believe these fears are unfounded, as
there are surely means to guarantee a proper licensing process without
    necessarily encrypting the standalone builder.

It's happened once before, with SuperCard and Digital Chisel. I can't blame RunRev for not wanting to be the second example.

Didn't you just state that the build process has been moved into the engine, so - again - why maintain the protection of the Rev standalone builder?


And, would it be possible to get access to the privileged information
Richard and Klaus received for creating the MC standalone builder?

Offhand I don't think that would be a problem, but I'm not Kevin so I should probably run the request by him first.

He'll probably ask what the purpose is, esp. given that an updated SB for MC is already well underway. What should I tell him?


Tell him I am keenly interested in the inner workings of Livecode as I have been all the time. This would enable me to make proposals and contributions for future improved standalone builders, too.

--
 Richard Gaskin
 Fourth World


Let me make a concluding statement:

As a member of the tolerated "MC IDE user group" and at the same time as a holder of a commercial license for Revolution/Livecode since the beginning (and presently up to 2013) I reserve the natural right to make recommendations and to criticize points and developments which I think need attention.

If I sometimes sound too aggressive, this is not meant to attack someone personally, but rather an attempt to make points clearer.

I am interested both in maintaining the MC IDE and in further developing Livecode, and I have supported these processes actively for many years.

My main platform for development at present is the MC IDE along with a number of add-ons I have developed myself. Here I am in a similar situation as Richard, whose main platform is also not Livecode, but a development of his own on the basis of the MC IDE (Is that correct?).

The reasons for that are many - and I will not elaborate them here again.

I will not rule out that at some point in the future I could switch over to Livecode altogether, when a level of maturity has been reached that will make working with Livecode comfortable for me.

Best regards,

Wilhelm Sanke
Prof. emeritus
Educational Technology
University of Kassel

_______________________________________________
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Reply via email to