Where Rev could be going...

Fri Nov 24 15:04:04 EST 2006

I have no business talking on this thread at all as I have no technical
ability or understanding in this arena, but I have an application that I
would like to serve over the internet so I have been following this thread.

What about a "very thin client" that, when a link is clicked in a web page
that references it, it downloads, executes and, when closed or dismissed in
some way, self-trashes.

It seems to me that the biggest drawback with Rev on the internet is that it
needs a client to execute locally if you are going to use palettes or other
Rev interactivity... Jim

on 11/24/06 3:33 PM, Richard Gaskin wrote:

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

-- 

www.TalentSeeker.ca   www.HiringSmart.ca/ns   www.KeepingTheBest.ca/ns
<http://www.OwnYourFuture-net.com>

Own Your Future Consulting Services Limited,
23 Shoal Cove Road, Seabright, Nova Scotia, Canada.  B3Z 3A9
Phone: 902-823-2339. Fax: 902-823-2139