Revolution => Flash
ambassador at fourthworld.com
Fri Oct 12 14:01:55 CDT 2007
Thank you Derek and Luis for the very kind words.
Derek Bump wrote:
> Why should a company choose to program in Revolution when they
> can use technologies that already work within a web browser?
Same reason they would choose RealBASIC or XCode or Visual Studio: they
need to make desktop apps.
When they want to make web apps they often use Dreamweaver with MySQL
> The current software market suggests that "all-in-one" web solutions are
Depends on what "all" means. Adobe Illustrator makes a pretty crappy
database, and FileMaker Pro is a weak illustration tool. :)
Sometimes it's not so bad for an app to nail a specific domain,
certainly before it branches out to address new tasks. I'd much sooner
see column alignment in fields, reshapable polygons, and a whole lot
more before we ask RunRev to devote development resources to something
like a plugin.
> It's easy to suggest that due to the popularity of Google
> Earth or Widgets that the web is dead, but it's not.
I apologize if my post suggested such a dismissal. Of course the web is
the single most important technology to have appeared in our lifetime,
and it's driving much of the modern world.
But the question is not necessarily limited to "Can we have a browser
plugin for Rev?"
Maybe a better question would be to step back and look at the bigger
picture, asking, "How can Rev contribute to my web development?"
All of the web apps you listed are important, but it's equally important
to note that none of them are driven by a plugin.
> I feel that developers need to realize that the web itself has become a
> psudo-platform. Revolution embodies the "Build Once, Deploy Everywhere"
> motto, I think that the Web should be included in the 'Everywhere' part.
The web is definitely an important platform, and has been since the late
'90s. Participation in the web is critical for any forward-thinking
company, but a plugin is not the answer.
Andre's two posts on the subject this morning point to a much more
valuable approach. And more importantly, what he proposes can be done
right now with what we have in our hands today.
Later this quarter I'll be porting an established desktop product to a
true zero-install web application. For some background on the app:
PHP. We're doing this because IT departments are asking for a
zero-install solution, and we're delivering it, and most of it with Rev.
We'll maintain the content management system we created for the app as
a Rev application, and will still ship the desktop app. But we're
adding exporters to generate the web pages (using parts of my WebMerge
product, also built with Rev), and migrating our custom search algorithm
to the server intact using Rev CGI.
It's also important to note that we're keeping one of the most critical
parts of the application in desktop form only. This module is a
decision support system used in emergency clinics, and those clinics who
rely on it can't risk potential network outage anywhere between their
terminal and our server due to earthquake etc. Indeed, it's precisely
during such catastrophic events that the software will be most
critically needed, since the emergency rooms will be full.
My hope in outlining this project is to illustrate one approach to web
deployment, a real-world example that demonstrates the sorts of ideas
Andre's brining up.
And in addition, it also provides an example of why some projects make
good sense on the web, and others make better sense on the desktop.
This project has components that work best in each.
We could summarize deployment options available to us today in three
- Desktop app
The traditional application experiences that still drives
- Web app
An application that lives entirely in the browser, ideally
requiring no additional software on the client side.
- Hybrid/Custom Browser/Helper app
Standalones empowered with Internet connectivity, which may
include HTTP but can also use a wide range of other common
protocols, such as FTP, IRC, and even custom protocols if
needed. They can store persistant data locally, and even
provide an offline mode if desired (I spend a lot of time
Each type of application has its own strengths and weaknesses, and no
single model will be best for all cases. So we just take a good look at
our application and what we want to do with it, and choose the model
which best serves our goals.
These aren't mutually exclusive, but instead compliment one another by
giving us a very broad range of options.
But best of all, all three can be built with Rev in a central role today.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the use-livecode