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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
