many small or 1 big?

[Sannyasin Sivakatirswami]

On Sunday, September 8, 2002, at 06:08  PM, Richard wrote on the  
use-revolution-request at lists.runrev.com wrote:

> Sounds like a good case for a Rev Player....
>
> -- 
>  Richard Gaskin
>  Fourth World Media Corporation

Forgive me for waxing long here, but this is a key theme, perhaps more 
than we realize.

1) Can't a standalone that serves no other purpose than to hold the 
engine and a splash screen serve as a virtual  "Rev Player." But then I 
guess one has the issue of doc/app binding for a double clickable stack 
(sans engine) that would auto boot from the above mentioned standalone, 
as well as libraries required...

2) If I understand the license agreement correctly, could one not ship 
the Rev app itself, minus all IDE  components and have it act as a 
"Player" --assuming one built a stack distribution with the necessary 
components in your stack... which is still a headache.... might as well 
build the standalone.

3) I am doing this now "in a way" (using Metacard because of memory 
issues... ) i.e. I email someone saying "go to ftp.metacard.com and 
download the version for your machine and then, after it is installed 
boot the attached application."  where: those individuals have zero 
interest in programming and wouldn't even think to ask about this being 
a 'starter kit" as such, for them its the same as downloading Real 
Player, Acrobat Reader or any other browser independent plug in... i.e. 
they will never even see the home stack... they just double click the 
app I send them which I build in Rev.

4) I have also installed MC, just the engine itself and nothing more, 
on various stations here for the editors who will use an app that I 
made for them...have yet to try that with Rev....

Possibly the paradigm of leaving dominant browsers in the dust and 
putting the internet to work as and how we want it to work would gain a 
lot of momentum with such a Rev player...  e.g. right now i am busy 
re-gurgitating  several thousand pages of print matter into HTML and 
mounting all that code inside GoLive for distribution because everyone 
believes that is the ONLY way it can be/should be done, and, today at 
least, they are right.... but it is months of work creating something 
less than satisfactory that could be much more efficiently and more 
elegantly done in xTalk. I have to do  amazing things like say "forget 
the index... it's not doable in HTML in the time frames we have." 
Whereas re-purposing a book index to make a hyper index for hypertext 
inside Rev would be a three day job at most.

All by way of saying a "skinny" Rev player would be great...My apps for 
team players in remote places are very much dedicated to single tasks 
(e.g. downloads one specific web page, allows it to be edited and then 
uploaded) and therefore require very few add ons (I just have to be 
sure to let the person be able to save, quit and copy text) But for 
broader apps  I think we might try to  come up with a consensus on some 
subset of libraries that the Player might carry with it... to virtually 
eliminate *any* need for distribution builds: ask, answer, print 
dialogs and minimal set of cursor icons and libURL come to mind as 
natural to have on board such a player.

The Player could do some exuberant unabashed Rev self promotion... I 
would have no problem with that... which in turn would relieve the 
developer with the task of branding his app with  Rev and give Rev much 
better "brand name' positioning in the process. This would allow for 
the distribution of •extreme• light weight apps by email with a single 
Rev  Player file for download sitting on some web site. I just love 
sending a 120K app to Malaysia, and then, when a revision is required, 
send the same... meanwhile the user only had one heavy download.

Hinduism Today
Sannyasin Sivakatirswami
Editor's Assistant/Production Manager
katir at hindu.org
www.HinduismToday.com, www.HimalayanAcademy.com,
www.Gurudeva.org, www.hindu.org

Read The Master Course Lesson of the Day at
http://www.gurudeva.org/lesson.shtml