Where Rev could be going...

Fri Nov 24 14:33:29 EST 2006

Bernard Devlin wrote:

> I want to continue this discussion a little further to see if my  
> understanding is correct: 1) any Rev app that would run in a browser  
> plug-in could only offer a sub-set of Rev functionality

Yes, browsers behaviors are a subset of all application behaviors.
On the desktop we can do darn near anything, but in a browser we're in a 
fairly small sandbox.

Remember, a browser is a desktop application.  And when a client-side 
application also requires a new plugin, the browser alone is an 
incomplete application.

> 2) there would need to be a lot of conditional coding in the engine
> to check which environment the code was running within, in order
> for the plug-in to know what it could and could not attempt to do.

That's one approach, which seems reasonably simpler than maintaining a 
separate code base.

> The former set of limitations is not that different from Rev running  
> in secureMode.
...
> So, we already have that concept of a player application with limited  
> functionality.  That looks to me like the engine already contains  
> conditional processing for secureMode.  I'm wondering if this browser  
> plug-in couldn't be done as an extension of secureMode.

It could, but the technical possibility still doesn't address the 
business case for doing so.  For example, note the extremely small 
number of developers who use secureMode at all, even though it's been 
available since before Rev 1.0.

As roughly a superset of browser behaviors, Rev already contains most of 
what a plugin would need.  For myself, and presumably RunRev Ltd., the 
question is not what's *technically* possible (Roadster already showed 
that), but what's practical in terms of the *business case* to justify 
the effort (the demise of Roadster and a great many other plugins in 
favor of Flash, DHTML, and Java arguably shows us that too).

> However, if we could make explicit what all the different
> limitations would be, then maybe the advocates of a plug-in
> will conclude that it is not something they would find 
> particularly useful (e.g. if it meant they had to code a
> different version of their app to work with a browser  
> plug-in.)  I'm still ambivalent about it myself.

This has been done time and again to varying degrees, e.g.:
<http://lists.runrev.com/pipermail/use-revolution/2006-November/089327.html>

To recap:

EVALUATING USAGE SCENARIOS
--------------------------

For myself and a number of other participants in this perennial thread, 
the emphasis has been on the business side rather than the technical, 
which I feel is a more appropriate focus.  In software almost anything 
is technically possible, so the question becomes whether it's worth doing.

Keep in mind that the true goal here is not to deliver Rev in a browser, 
but to deliver an application in a browser.  This means that existing 
solutions (Flash, DHTML, Java) play a role in this evaluation, since 
there's no point in making something in Rev just for the sake of doing 
so if an existing deployment solution can deliver the same or better 
software experience at an affordable production cost.

THE GAUNTLET: A USAGE SCENARIO METRIC
-------------------------------------

In all of these discussions, what I haven't seen yet is the usage 
scenario which meets these criteria:

_ The application must reside in a browser window.

_ The application does not need to store any data on the client
   beyond of the limits of cookies.

_ The application's usability is not impaired by the limitations
   of the browser (no custom dialogs, no palettes, no menu bar,
   etc.).

_ The browsers used to run the application can be expected to be
   custom-configured with the necessary plugin to do so.

_ The same user/administrator willing and able to custom-configure
   their browser with the required plugin is for some reason unable
   to do the same with a custom dedicated application.

_ Flash, DHTML, and Java cannot deliver the desired software
   experience at a reasonable cost.

In my own discussions with clients, we never get more than halfway 
through that checklist before we decide that we can either use Flash or 
DHTML, or deploy a custom app.

If the Rev community can find a real-world usage scenario which meets 
these criteria, we then would need to see a fairly broad number of such 
cases to warrant the effort to design, build, test, deploy, and maintain 
a Rev plugin (I'd love it if RunRev would make custom doodads just for 
me, but they need to address broader concerns than just mine if they're 
to stay in business).

In the absence of evidence of such a pervasive need, it seems there are 
many other areas where RunRev Ltd. can get more bang for their 
development buck than by making one more solution for squeezing apps 
into a browser.

ALTERNATIVES FOR BROWSER DEPLOYMENT
-----------------------------------

For those for whom the attraction of the browser remains compelling, I 
can't stress strongly enough how much more beneficial it might be for 
their users to consider DHTML instead, perhaps using Rev for layout and 
design.  DHTML is just plain ol' ASCII so it's a breeze to generate, and 
as just one example of this sort of thing I have a simple 
proof-of-concept SVG exporter in RevNet (see 
Development->Plugins->GoRevNet, then "Stacks") -- anyone's welcome to 
expand on the ideas there, as Alejandro has already done quite nicely 
(that and many other nifty examples of his genius and dedication are 
available at his site: <http://www.geocities.com/capellan2000/>).

Then again, there are so many good DHTML tools out there it may not be 
necessary to use Rev at all.  For example, slide show apps and more are 
simple drop-in JavaScript snippets in GoLive, and the Dreamweaver 
community has delivered an even broader range of simple point-and-click 
JavaScript-based solutions.

DHTML opens up an arguably better deployment option by delivering the 
one thing a new plugin can't:  true ubiquity.  The JavaScript 
interpreter is already built into all popular browsers, so if one's 
looking for client-side scripting it's rather hard to beat it for ease 
of deployment.  No plugin, no installation; all that's needed is a URL. 
  Same for Flash and Java, both pre-installed for many years.

BEYOND THE BROWSER: DEDICATED APPS
----------------------------------

For everything that can't be done affordably in DHTML/Flash/Java, it's 
worth considering following Google's trend of going beyond the browser 
into dedicated net-savvy apps.  Just as Google Earth runs circles around 
Google Maps, Rev-based apps using libURL can deliver a lot of great 
solutions easily right now.

RevNet is just one modest example, which substantially replicates much 
of the AOL client experience in just a few hours' work (makes one wonder 
why AOL doesn't cut their client development costs by some 90% and use 
Rev <g>).  And then there are Reactor Lab (<http://reactorlab.net/>), 
Digital Dynamic Maps (<http://ddm.geo.umass.edu/>), Revzilla 
(<http://www.sonsothunder.com/devres/revolution/downloads/RevZilla2.htm>), 
and others in the Rev world which take the paradigm much further.

Revzilla is an especially interesting example to me, as it represents a 
truly independent client-side solution:  you can use a web browser or 
Revzilla to interact with the same server application; the server never 
knows the difference.

SUMMARY
-------

We have no shortage of deployment options available to us right now, 
within and beyond the browser.  The main question isn't technical, but 
simply which deployment option makes the most sense from a business 
perspective for the application at hand.

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