MetaCard and Rev 2.7 + engine

Richard Gaskin ambassador at fourthworld.com
Thu Jun 22 13:54:21 CDT 2006


J. Landman Gay wrote:
> Klaus Major wrote:
>>> On February 14, 2006 Jacqueline Landman Gay  wrote:
>>> Installing Revolution 2.7 into the MC IDE
>>> ...
>>> There should also be no need to license the engine in Revolution 
>>> first - the engine will ask for a license key the first time it is 
>>> run, regardless of where it is run from.
>>> ...
>>
>> Does this mean that we do not need a special MetaCard license key 
>> anymore?
> 
> That's a good question. I don't know. But I'm guessing you would, 
> because the old MC Home stack checks for a license stored in Home, and 
> the new engine also checks for a license stored elsewhere by the engine. 
> So maybe we need both? Of course, most of us are using a 
> previously-licensed Home stack, so that issue becomes moot.

Experiments here confirm that v2.7's licensing is indeed fully 
self-contained, which has several positive implications for both RunRev 
Ltd and those of us who use MC, Galaxy, and other alternative IDEs:


- The new engine prevents unauthorized scripting on non-licensed
   platforms.

   Rev Studio deploys to any platform, with the only restriction
   being the platforms on which the user is allows to author on.
   These terms no longer conflict with the freedom of MetaCard's
   multi-platform Standalone Builder as they did in the olden days
   when Studio deployment was limited to specific purchased platforms.


- The license mechanism no longer involves the Home stack.

   In older versions the Home stack contained special licensing
   info in a proprietary format in one of its substacks.*  With
   this reliance on the Home stack and the Home stack's own built-in
   authorization mechanism, this prevented RunRev from enhancing the
   license code easily for their engine protection and also required
   them to maintain and generate special MetaCard licenses on request.
   With 2.7 it appears they no longer need to be saddled with this
   burden.


- The boot sequence is simplified.

   In older versions, the engine would look for licence.rev or home.mc
   and then verified that the file contained the special license info.
   In v2.7 the licensing is handled internally in the engine, so the
   Home stack is now merely used as a launcher for the IDE.  Any
   stack named home.rev can contain a script to launch any stacks
   serving as your development environment.  If you haven't licensed
   your engine, it simply won't load Home and you can't continue.


With the new Studio license terms and more secure engine-based license 
enforcement, it seems RunRev has given their users the freedom to choose 
any IDE while giving themselves greater security in protecting their 
product.  With the broader deployment options enjoyed by Studio users 
there is no conflict with any MC IDE feature and Studio users are 
finally able to use the MC IDE, or Galaxy or any other IDE, just as 
Enterprise users have always been able to.

With the growing number of IDEs, the Revolution community can enjoy any 
number of environments tailored for their specific tastes.  FlipsIDE is 
rendered obsolete by this new simplicity, and I'm working on a new 
replacement named DarksIDE which will simplify installation of MC or any 
other IDE without affecting any behavior in the Rev installation.

This is a significant win-win solution, and I applaud Kevin and Mark's 
insight in making this very useful new licensing mechanism.


* The special proprietary license properties in MC's Home stack 
apparently mean that stack is in a unique format.  If you're using v2.7 
you will definitely want to be working with a COPY of your MC Home 
stack, as it's the only stack I've seen which cannot be reverted to the 
v2.4 stack file format -- once you convert the MC Home stack to v2.7 you 
can't go back with that copy.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com


More information about the metacard mailing list