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

[Richard Gaskin]

 From Andre, cont.:


Web applications usually have a server side component that that deals 
with core business logic that is not possible to be dealt by using 
javascript on the client side. We can map that to stack script and make 
the stack script a cgi/fastgi whatever. If we write a nice RPC system we 
can make the stack script hold the server logic and export it as methods 
to be used by the client side which is CSS+HTML+Javascript+A Human.

To illustrate my ideas, imagine a simple money conversion. In the web it 
would be two fields and two popups and one button. the two fields would 
hold the amounts, the two popups the currency types and the button would 
convert from one to the other. The client side would use AJAX techniques 
to make the life of the user easier, so simply clicking the button would 
do a roundtrip to the server, convert the amount and then using 
javascript + DOM manipulation it would insert the answer in the text 
field. How would that map to Rev. The fields and the popups and the 
button all have an equivalent on the Rev standard tool pallete, we would 
need a new web-savvy inspector to accomodate the needs of positioning 
and ids/class stuff for xhtml. The server component might just be the 
convert function on the stack script. Okay we have our maps. How the 
magic conversion occurs then? We need a new "web distribution builder" 
tool that would scan and process a stack converting it all to HTML + CSS 
+ Javascript + CGI. This tool would pick the stack script and pack it as 
a CGI and expose it's functions thru some RPC mechanism, it would 
convert the card layout to a web page format using the web-savvy 
properties created by our own web-savvy inspector to guide it when 
needed. It would convert the control scripts to javascript and relay 
each call to a method that is inside the stack script to a RPC call to 
the server component, for this to be feasible the script on the controls 
should be as small and direct as possible, maybe just variable bindings 
and the call to the stack, nothing more would be allowed, let me 
illustrate such control script conversion.

Transcript button example:
Code:

on mouseup
   put field "amount" into tAmount
   put field "currency type" into tCurrencyType
   put convertCurrency(tAmount, tCurrencyType) into field "result"
end mouseup


web-thing conversion

The button would be something like this

Code:
<input type="button" onmouseup="javascript:buttonMouseup()" />
meaning the html button has a javascript methond connected to it's 
mouseup event. then we have a almost line by line conversion.
Code:

buttonMouseUp() {
var tAmount  = document.getElementById("amount");
var tCurrencyType  = document.getElementById("currency type");
document.getElementById("amount").innerHTML = RPCCall("convertCurrency", 
tAmount, tCurrencyType);
}


See, if the conversion is just variable binding and method calls, it's 
pretty straigth forward, just need to create some RPC mechanism, it 
might be XML-RPC, SOAP, REST or something new. Let me make a resumé.

We need a new tools pallete that is able to drag and drop web-mapable 
objects.

We need a new inspector that is able to deal with the features we expect 
from a web object such as relative position.

We need a new distribution builder that is able to pick that stack and 
convert it to HTML & Friends + CGI.

You will ask, but I still need to upload everything to test and that 
spoils my pure xTalk development experience and I will answer: no you 
need not. We have RevHTTP transcript based web server that can run 
inside the IDE, a simple IDE plugin running the server will allow you 
the standard xTalk experience, develop live on the IDE, switch to the 
browser, load the page from inside RevHTTP that's live on the IDE, full 
xTalk experience, no compilation needed.

Everything I said can be built now, it doesn't even need to be built by 
the RunRev team, it all can be built in pure transcript just by adding 
plugins to the IDE. It can be done now, all it needs is leadership and a 
team of developers. Thats what I think that needs to be done. That's how 
I envision developing for the web using Runtime Revolution, I don't know 
if I was clear and I really want to talk about this thing to make 
everyone understand what I am trying to talk about.

It's now 2:53 AM... I think this email to too big for the mailserver to 
allow me thru. I'll try anyway.

Andre
_________________
Technology shall set ya free!