Possibility to generate SVG user interfaces or design objects embedable within web pages would possibly compete with the xTalk "brand" used in the same product, but it could also attract new users willing to develop "in SVG and has a potential for the mobile devices too. If to listen to what W3C says, then most browsers (and handhelds) within a few years should have native xml based SVG support as an alternative to the proprietary binary format of flash. Current situation is that MSIE has own vector graphics format - VML and it is unlikely that it will drop it in the near future. But one can easily get SVG plugin from Adobe... In fact Google maps uses both SVG and VML... On the other hand the SVG niche is already reserved by Adobe (http://www.adobe.com/svg/) which now is also an owner of flash and provides authoring tools for both... Another way could be ASP (Application Service Provider) model. But a prerequisite for this would be possibility to EASILY describe and script stacks using XML, stylesheets and script-sheets - in xhtml manner. This would attract more web developers and designers who will likely purhase Rev IDE later on. This category of people frequently switch between hand coding and WSIWYG authoring. In this model some enhancements should be done for the Revolution player to make it more attractive as an ASP platform alternative to web browsers. A centralized index of Revolution authored ASP services on a global scale (like google for web pages) might increase chances of it being used... Of course, the possibility to compile stacks into standalone desktop apps, encrypt/obfuscate the code or compress stacks should be limited to those who purchase the IDE ;-) And in general it would be useful enhancing Revolution's 3D capabilities making it also an IDE for 3D graphical user interfaces. Not many competitors in this field yet (like XAML on Windows Vista), but all the major platforms (Windows Vista, SUSE Linux, Mac OS) have already moved towards this target. And I do not know anything that could provide cross-platform 3D GUIs so far. All the best! Viktoras -------Original Message------- From: Richard Gaskin Date: 11/24/2006 9:33:38 PM To: How to use Revolution Subject: Re: Where Rev could be going... 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 _______________________________________________ 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
