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 > [email protected] > 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 _______________________________________________ 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
