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