Revolution and the Web, feedback wanted, Part 2 of 3

[Richard Gaskin]

 From Andre, cont.:


First, let me begin by my all-wise-axiom

People don't want Rev to run on the web, they want the development 
experience of xTalk and to be able to deploy for the web.


Explaining, no one really want Rev on the web. Having a Revolution built 
application on an end user machine or a <favorite language> built 
application on the same machine, is the same thing for the user. The 
difference is on the side of the developers. We like xTalks because of 
the stacks, cards, properties, english like language, way of interacting 
without compiling and this kind of stuff. We wish that developing a web 
application would be as easy as that. If we had a little xTalk 
environment that would allow us to visually create our web gui and use a 
xTalk language to code the server side without the need to compile, 
upload, debug just to do our testings, I bet people would be very happy.

People keep asking for flash export, web plugins and java bytecodes, not 
because they think those technologies are a superior thing that RunRev 
should incorporate but because they can't stand developing using Adobe 
Flash MX, Visual C/C++ and NetBeans. We're often looking by the wrong 
side of the problem here on this list. No one wants flash support 
because they think actionscript is superior to transcript. They want 
flash support in rev because doing all the work on flash mx sucks. 
People here realized that XHTML + XSLT + PHP is as simple as the holy 
roman empire was holy, roman and an empire.... we want the easiness of 
Runtime Revolution with it's marvelous and unmatched development 
experience and we want it because as we realized this is the right way 
to do things, we can't go back to the PHP... (some people can but 
belive, if the could do it in transcript, they would).

Now that I've established the problem, let me talk about the solution I 
think. This is not coming out of my mind all of a sudden, I've spent the 
best part of the last three years thinking about it and talking with 
very wise people here, so I expect the readers will at least give me the 
benefit of doubt and read till the end. I also want feedback on this 
ideas because they may become something I'd devote much of my free time.

The problem of converting from Revolution to the Web is that again, 
those two things don't match, it's comparing oranges to shoes (Jacque, 
this quote is to make you happy). Web is a stateless technology to 
display hypertext, we're taking it to the limits by using CSS + XHTML to 
create rich user interfaces, javascript to give it half a brain and 
xmlhttprequest object to fake state in it. Revolution applications have 
a rich user interface out of the box, a whole brain and knows it states. 
If we try to convert from Runtime Revolution to the web we will stumble 
in many blocks such as:

     * web is client/server, normal stack applications are monolitic. 
How to split stack code in client/server way? should all go in the 
server and be executed as CGI, to make this as transparent as possible, 
all calls to code would be done using xmlhttprequest object (AJAX 
techniques) and this would make a lot of server roundtrips and waste a 
lot of bandwitdh and server CPU cycles or should we convert some parts 
of it to Javascript and run it on the browser and allow just some logic 
on the server, this again poses a problem because I can't think of any 
fail-proof way to code a tool to do that decision without human 
intervention.

     * Revolution is rooted into the stacks, cards, objects paradigm. 
The most used control is probably the button and the second is probably 
the field. The web is rooted into HTML which seldon uses buttons or text 
fields (in the text entry style). To map from a runrev stack to the web, 
the converter should be wise enough to deal with that problem.

     * The message path can be faked but some things cannot. Send in 
time can't be used. There's no persistence, as soon as the cgi returns, 
it life ends, there's no more cycles to use (unless you're using 
javascript in a loop in the browser or fastcgi in the server) so things 
like send in time or reacting to an event, can't really happen. No way a 
code in the server will receive a mouse enter event unless this thing is 
trapped by javascript, encoded somehow and send using a HTTP request to 
the server.


This are just some roadblocks on the conversion from revolution to the 
web, there are many more such as the engine being single threaded (which 
is a non-issue if you're using cgi but a big issue if you're using 
fastcgi). If you want to have a simple glimpse of the nightmare this 
conversion is just think how the following line should behave on the web:

Code:
   go stack "another stack" with visual effect push left


Will this use a 302 redirect? a meta refresh tag? the effect will be 
done with CSS and DOM manipulation? what if there's no javascript in the 
host browser?

Converting from Runtime Revolution to the Web will prove to be an 
herculean task if anyone expect all kinds of stack to run. I don't think 
such approach will ever work right and I have indeed another solution to 
market. I'll use another axiom.


There are more helicopters in the bottom of the sea than submarines in 
the sky.


Converting from Revolution to the web is the same thing as put a 
submarine in the sky. We should aim to put the helicopter in the sea, 
it's far easier, actually it happens all the time. Let us look at our 
problem backwards. Okay we can't convert from Rev to the web, but what 
if we can convert from the web to rev?

What we want? We want the marvelous development experience of xTalk and 
to be able to deploy that on the web. How we will achieve that? By 
mapping the web back to Rev.

Whats the root thing on the web? The page. How to map page to rev, by 
using cards, each page is then a card.

What encloses a web application? a collection of pages and it's 
supporting server side code. How to map that to rev, by using stacks, 
each stack a single application package or component.

We know that our tools pallete doesn't match the usual web controls, so 
we need a new pallete with "web-savvy tools" this tools could be a 
simple modal plugin with new tools such as TEXT, IMAGE, CONTAINER, and 
this tools could be easily converted to the usual HTML + CSS. For 
example HTML uses nested nodes such as /html/body/div/p for a paragraph 
that belongs to a div. How is that different from Rev groups, if you 
group all your card controls in a parent groups and had a nice "web 
inspector" to give it a type "div" we could simply map the tree nature 
of HTML back to Rev by using nested the groups. So all we need is a new 
tools pallete able to create objects that can be easily converted to 
their web counterparts and a new inspector that should have features to 
aid this conversion such as "positioning tools", most of the CSS will 
use relative based position while rev uses absolute coordinates, a new 
inspector to deal with that kind of stuff.

Take notice that what we're doing is not think how to map revolution to 
the web but the other way around, how to pick the most common web stuff 
and map back to rev so that after we do this mapping, we can simply 
write our web-tools.


(continued in Part 3 of 3)