Some afterthoughts concerning the enigma of "generic players"

[Wilhelm Sanke]

Trying to catch up on the discussions, I am happy to eventually find 
Jacqueline's definition of a player (excuse the split infinitive):

On Sun, 26 Feb 2006, "J. Landman Gay" jacque at hyperactivesw.com in thread 
"Rev licensing - post factum rulings ???"
had written:

> The only change -- which isn't really a change, but is now being
> enforced -- is that you cannot create a generic player app that is
> distributed for the sole purpose of providing "player" capabilities for
> stacks unrelated to your own software.



Hi Jacqueline,

if your interpretation of the intentions of RunRev would be fully 
endorsed by RunRev themselves (I take it you are near to the inner 
circle of RunRev, but not actually a spokes(wo)man?), this would be 
another step in the right direction.
The definition still leaves room for more interpretation, e.g. how do 
you define "unrelated", but one could ask, why is the new policy 
"enforced" at all and does this really  serve the "philosophy" of 
"Revolution" and is it necessary for the commercial success of RunRev? 
I'll  address aspects of this later.

> Aside from StackRunner (which is Ken Ray's product, not Richard's) no
> one else in the history of Revolution has ever created such an animal
> and no one else is affected.
>
> -- Jacqueline Landman Gay | jacque at hyperactivesw.com HyperActive 
> Software | http://www.hyperactivesw.com



Given the ease with which it is possible to produce a player application 
I had a different impression, which is also expressed at the beginning 
of my web page <http://www.sanke.org/MetaMedia/Samples.htm>:

> "Sample Applications
>
>  If not marked as "standalone", these sample stacks require either a 
> player or one of the IDEs "Metacard" or "Revolution" (to page 
> "Metacard/Revolution"). Various player applications are available from 
> Revolution and Metacard users, as it is not difficult to create such 
> an application. Revolution offers the "Dreamcard Player" for licensed 
> users of the Dreamcard version of Revolution (because this version 
> does not offer the possibility to create standalone applications).
>
> The player offered below is just one of many possible solutions.
>
> MC-Player (zip-file 883 K) Basic version of a player to open and save 
> Metacard und Revolution files ("*.mc" und "*.rev") for offline use".



This Player has been sitting there on my website since I added the 
"MetaMedia" part to my personal domain two years ago. It dates back to 
pre-Revolution times and was formerly to be found on the public part of 
the ftp-server of my institution, if you were able to navigate through 
the maze of directories.

I mentioned this Player in recent posts (responding to you and Chipp, 
Feb 17 and 18) in the context of the discussion about 
"stackfileversions" and the building of standalones with version 2.7. I 
have no intention to propagate this player - it needs to be updated 
anyway -, his purpose is to provide another option for our students to 
view the sample stacks, but of course it is technically possible to open 
(m)any Rev stacks, provided either the Player or the stack contain the 
specific resources needed to run the stack.

Applying your definition above, the player indeed does not have the 
"sole purpose of providing "player" capabilities for
stacks unrelated to my own software".  In that sense it surely does not 
fall in the "strange animal" category like Ken's Stackrunner, as you put 
it above.--

When I stated on my website "Various player applications are available 
from Revolution and Metacard users", I had also in mind as "players" in 
a broader sense stacks like Richard Gaskin's "Go RevNet" that downloads 
and runs a number of selected stacks (and if converted to a standalone 
would constitute some kind of "player") and likewise stack "tmpanel" of 
"Tactile Media", the player of the "Himalayan Academy" and others, 
including also our "E-Learning" stack 
(<http://www.sanke.org/Software/E-Learning.exe>) which we used during a 
nation-wide e-learning conference at our university three years ago to 
demonstrate - along with the above-mentioned stacks of Richard and 
others - that it is possible to implement e-learning without the help of 
net-browsers.

But above all my guess of other players being at least around (if not 
immediately available) was based on the fact that it is quite simple to 
put together an elementary generic player. All you need is a stack with 
two buttons:

Button 1 contains the two script lines

"answer file "Choose a stack" with filter "*.mc;*.rev" # (for Windows)
  go to it",

button 2 will save the respective topstack.

You could add a third button using "ask file" if you want to provide the 
option to save the stack under a different name.
Now turn this stack into a standalone. Everybody familiar with the very 
basics of Metacard/Revolution is able to produce such a player in five 
minutes.

You get an even more basic generic player (I mentioned that in my 
response to Jacqueline on Feb 17) when you rename file "standalone" - 
needed to build standalones in versions 2.7 of MC and Rev - to 
"MyWonderfulGenericPlayer" or whatever and add an ".exe" extension; now 
you can drag any stack on that filename and it will be opened.-

A wide variety of generic players is possible, differing in the amount 
of resources that are contained in the player itself or - on the other 
hand - required as embedded resources in the stacks to be launched.
Ken's Stackrunner is far more sophisticated in that sense, compared to 
the old Player on my website, which contains only the answer and 
ask-dialogs, the Metacard icons, substack "file selector", the cursors, 
message box, substack "execution error", stack "libURL" (not needed in a 
non-web application) etc..

The DreamCard Player was clumsy and overloaded - and therefore rather 
big - when it was released. I criticized that at the time pointing out 
simpler solutions, and got flamed for that.

An "all-purpose" player would need to include all possible resources for 
any kind of stacks, meaning including all libraries, dlls, i.e. about 
half or more of the whole IDE and its supplementary stacks.
What is certainly important is to strike a sound balance between putting 
resources into the player or the stacks. Happily, users of the MC IDE 
can use the "Resource Mover" to put needed resources into a stack, but - 
as Rev users need to do if they are not building a standalone - there is 
of course the extra option to manually transfer resources.--

There are a number of situations where some kind of a generic player is 
indispensable, one reason being the size of MC and Rev standalones. 
Exe-files in other programming languages contain only the directly 
required elements. Such files created with Turbo Pascal or Delphi are 
rather small. Even with one of the other X-Talk languages, e.g. 
"Toolbook", you can get relatively small executables.
We handle this problem for part of our language students as follows: The 
students get a restricted generic player, capable of  running stacks 
with a specific extension other than "mc" or "rev". Thus we are flexibly 
able to provide for download and learning stacks of small size that can 
be easily updated or we can even add new stacks with different filenames.-

Coming back to the question of the "enforcement" of a new policy.
Let us imagine someone produces a generic player and even sells it as a 
commercial application you have to pay for. How could that possibly hurt 
RunRev in any way if they offer an even "free" player? As RunRev does 
not "sell" their player, how could an alternative player impair them? An 
alternative player would possibly show the variety of solutions feasable 
with such wonderful X-talk languages and therefore support and promote 
the distribution and acceptance of Metacard/Revolution - and not 
excluding the possibility that the RunRev team may even gain new 
insights from solutions they could not bring about at the moment, 
because there are so many tasks at hand to be solved. Every creative 
effort from other members of the Rev community should be honored and is 
a possible contribution to improvement.-

A last remark: At some place of the discussion I remember the new 
"Media" brand of Revolution was mentioned as one reason to introduce a 
restricted player policy(?). We do not yet know much about "Media", as 
it is not yet released (although you can already pay for it), so I have 
to reserve judgment here. But if this really is the underlying issue and 
it is really important to set "Media" definitely apart from "Studio", 
"Dreamcard" etc. - which I cannot imagine why in terms of running such 
stacks - then it must be easy to configure "Media" and its player in 
such a way that other generic players produced with other brands of 
Revolution cannot open and run Media stacks.

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>