Revolution => Flash

[Luis]

Pleasure. Had to be said.

I think most of this might stem from hopeful developers, especially 
newbies looking at the Rev platform and its deployment capabilities, 
hoping that it will also go that extra step.
Something like my gripe with audio (have to drag that back up again...): 
I saw its audio capabilities but didn't check it out fully, so I got 
stuck halfway and then gave it up. It seems like such a small step, yet 
it's not there.
Some may feel, newbies or old hands at Rev, that that little extra step 
onto the web will be all they will need to get their great new idea out 
to millions. I feel for them.
Note the RevBrowser built in to Rev: That can be misleading, and I can 
see many thinking to buy on the possibility that this is like a browser 
plugin.

Cheers,

Luis.



http://blog.reindel.com/2007/10/11/adobe-air-answers-a-question-that-nobody-is-asking/

Richard Gaskin wrote:
> 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.
>