The GENIUS of stacks

[Chipp Walters]

Dan contacted me a couple of days ago for my thoughts on Rev vs RB. Of 
course, I'm a big Rev fan and have only spent a bit of time with RB, but 
here are some observations.

I talked with my partner, Chris Bohnert about this. He's a very strong C 
programmer (wrote both altBrowsers for Mac and PC) who also works with 
VB a lot-- and frequently peruses the RB list. I've dragged him kicking 
and screaming into Rev development, and while his interfaces are nothing 
Scott Rossi would be proud of, he's been able to build some very 
complicated Linux utilties for (now happy) clients.

Here's one thing that differentiates Rev from other standard programming 
languages:

1) Rev has stacks. This often overlooked and misunderstood concept is 
pure genius from it's creators.

2) Building a self-updating application is trivial in Rev. Not so in 
other development tools. Because Rev can download and run a stack IN 
PROCESS, it makes it simple to check for an update and download it:

pseudocode:

launch splashscreen app
check for version -> (ONE LINE OF CODE!)
if URL "http://www.chipp.com/myversion.txt" is not equal to fld 
"version" of stack "C:/mainstack.rev" then go stack URL 
"http://www.chipp.com/mainstack.rev"

to do the same in RB or others, you'd have to:

pseudocode:

launch checker app
open sockets, setup data transfer, get data, parse data, check data 
against a stored registry setting or preferences setting then if different:

download the new executable main application (because they can't load 
code IN PROCESS)

launch the main application

close the checker app

This is much more difficult and has the added disadvantage of launching/ 
maintaing 2 applications and the associated download overhead of the 
'engine' (which does not need to be downloaded in the Rev example).

3) Maintaining source is much easier as you only have a single binary 
stack to ever worry about. In the example above, the binary main stack 
is completely cross-platform (Mac/Win/Linux) and is the only source code 
necessary for the application. So, there's no need to save/compile 
different version for Windows and Macs. A huge time-saver!

3) Stacks are not only good for cross-platform application development, 
but they're also unsurpassed as a binary file structure.

For instance, say you want to save an Image, Audio file, bunch of text, 
and a video (think Premiere project). How easy is this in Rev? Just 
create a new stack, put the files in it, and save it. That's it.

create new stack "multimediaFiles"
create new img "fred"
put URL "binfile:C:/title.jpg" into img "fred"
create new fld "theText"
put URL "file:C:/test.txt" into fld "theText"
import videoClip from file "C:/test/video.mov"
import audioClip from file "C:/text/audio.wav"
save stack "multimediaFiles" as "C:/test.rev"

Try doing that in as few lines in ANY other authoring package! I find I 
regularly use stacks as GREAT cross-platform binary document storage. 
Not only are they great for storing data (as shown), they can also store 
any Rev object (including groups!) as well. Here's a great use of this 
feature (I'm using it now).

I've got this rather complex image editor I'm working on. Think 
Photoshop. I want to support multiple undo's but it's a real pain. 
Here's how I do it. I have a group "Canvas" which has all the layers of 
images and text in it. Any time I make a change to grp "Canvas", I save 
a copy of the group into stack "undo." Now, I can easily 'undo' as many 
steps as I need by just copying the appropriate grp from the undo stack! 
Simple :-)

Also, stacks are great for storing other things. For instance, say your 
application has a PDF help document associated with it. And say you want 
to deploy a single 'no installer' executable. If you're on Windows and 
want a single executable, it may be stored anywhere on a user's hard 
disk, how will the app know how to get and where to find the PDF doucment?

Easy, just 'suck it up' into a custom property! Then 'spit it out' when 
the user needs it.

So, during development you would:
set the uMyHelpPDF of stack "myApp" to URL "binfile:C:/help.pdf"

now, it's stored 'in the stack'. So, the next time the user presses the 
help button, it checks to see if the help.pdf file is in the same folder 
as the application:

if there is a file "help.pdf" then
   --> LAUNCH IT
else
   --> SPIT IT OUT
   put the uMyHelpPDF of this stack into URL "binfile:help.pdf"
   --> NOW LAUNCH IT
end if

Once again, just too easy! Well, there are quite a number of other 
differentiating features I could mention (especially string 'chunking') 
but hopefully the above helps some of you to think about stacks in a 
different way! Perhaps some others would like to chime in about the 
differences they see.

:-)

Chipp