Revolution => Flash

[Richard Gaskin]

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 
and PHP.


> The current software market suggests that "all-in-one" web solutions are
> successful. 

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:
<http://www.runrev.com/newsletter/april/issue24/newsletter2.php>

We'll be using a combination of HTML, JavaScript, MySQL, Rev CGI, and 
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 
categories:

- Desktop app
   The traditional application experiences that still drives
   most computing.

- 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
   on trains).

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.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com