Where Rev could be going...

Fri Nov 24 17:39:18 EST 2006

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 
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