Revolution and the Web, feedback wanted, Part 2 of 3
ambassador at fourthworld.com
Mon Nov 27 23:39:43 CST 2006
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
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
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
* 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
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
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:
go stack "another stack" with visual effect push left
Will this use a 302 redirect? a meta refresh tag? the effect will be
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
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)
More information about the use-livecode