I sent this first to the use-revolution list but I think it was reject for being a big email.
Again on this list we touch the topics of browser plugins, flash export and other possible web related features. People from the RunRev team came forward and asked us for feedback and requests and many answered to this call. This email will be my thoughts on the topic of web and rev, it will be a very long email and I'll touch many topics but in the end this will remain an opinion piece and others may have a different point of view. I hereby apologise for my lack of english grammar skills and my typos, even before they occur. English is my third language, portuguese is my first, cursing my second and english my third. I'll first talk about flash, web browser plugin, java bytecodes, I'll be against them all, then I'll talk about what I think is the future and that it can be done now if people help.
It's been mentioned before that Revolution should export it's stacks to flash, I don't think this is feasible not only by a technical standpoint but also for a theoretical point of view. Flash is a multimedia presentation authoring tool. Runtime Revolution is a turing complete application building language and IDE. Revolution has features such as database access, tcp and udp networking, native GUI support which don't map well to Flash. I am not even touching topics such as the unique nature of stacks, cards, objects, customprops and the message path. I don't think the feature set and the mind set behind those two apps map well to each other, so therefore, I recommend against such solutions but the SWF format is open and anyone is encouraged to try some experiments.
Other possible solution was the creation of a web browser plugin, this is certainly more attractive to me than flash and more feasible. The idea of a plugin although is very hard because not only RunRev team would have to support lots of platforms (at least linux, windows and mac os x) but also each browser for each platform (safari, mozilla, explorer, opera), the amount of resources to create such thing would be enormous. Also what is the real difference between downloading the Revolution Player and having a browser plugin? Both will be about the same size but the plugin will be confined to the browser canvas (okay, it might be able to spawn its own windows too) and the Revolution Player one will be running on the "real thing". As far as my experience goes with Revolution Player, if any user needs to use my software, he will gladly download the player, he acknowledges no difference between downloading a player and a plugin. The player is less work for RunRev as a windows player will work in every windows, a browser plugin will depend on the browser version. So I'd rather use the Revolution player than a plugin.
The idea of making the engine generate java bytecodes is very entertaining because this would enable us to use revolution to build servlets for our web server end, midlets for our cellphone or pda programming and applets for those that really want to be confined to a browser canvas. I don't know much about java bytecodes although I put a book specially about generating java bytecodes from languages that are not java in my Safari bookshelf. The idea is very nice except for the fact that the WHOLE RUNTIME REVOLUTION ENGINE WOULD NEED TO BE REWRITTEN, sorry for the all caps, but we needed emphasys. To create such bytecode thing, a new engine would need to be built, we would not be able to re-use none of the C/C++ code. A new engine from the scratch. We don't have the resources for that either, writting a new engine?! Just pick everything scott raney did, all the things runrev added during the last years, throw it all away and build it again just for using java bytecodes. I don't think we can do that now.
Okay, my rant is finished, let us talk about new things, about Revolution and the Web in the way I see it.
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 stablished 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.
Code: Select all
go stack "another stack" with visual effect push left
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.
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: Select all
on mouseup
put field "amount" into tAmount
put field "currency type" into tCurrencyType
put convertCurrency(tAmount, tCurrencyType) into field "result"
end mouseup
The button would be something like this
Code: Select all
<input type="button" onmouseup="javascript:buttonMouseup()" />
Code: Select all
buttonMouseUp() {
var tAmount = document.getElementById("amount");
var tCurrencyType = document.getElementById("currency type");
document.getElementById("amount").innerHTML = RPCCall("convertCurrency", tAmount, tCurrencyType);
}
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