Folks, This is me revealing me some secret ideas I had in the last few years. I kept this somewhat secret for many years because I wanted to implement it but I came to the realization that I don't have the time to do it alone and that is the exact kind of project that benefits from a FOSS initiative.
The project is to build a suite of tools to run inside Revolution IDE to allow conversion of Stacks into a web scaffold that can be further tailored and tweeked for deployment as web apps. as Jerry, Sarah and Mary demonstrated it is possible to process a stack and convert it to some other format. David Simpson also has conversion tools built that can convert php and basic back to Rev and even more. All this done with small teams. What a big team such as our community could build? (<-- rethorical question) I remember talking with Mark Wieder and Richard Gaskin during a conference in Monterey, I think I have found the pathway that would enable us some quick conversion from Rev to the Web. The trick is not to try to convert a common Rev stack, if you try to convert all kinds of Rev controls and stuff, you end up basically reimplementing the engine, this is kinda hard. What we need to leverage is not Rev engine and controls but Rev IDE using the tools we like but not the standard Rev language and controls. I will detail below the tools I think are needed: TWO ENVIRONMENT FRAMES First of all to understand this you need to understand an important concept. For this system to work, there will be two different environment frames running. One is the Rev IDE and Engine process which understands RevTalk and is our development tool. The other is a background webserver that is the target of our development tools and does not understand RevTalk but Javascript. Actions on the development environment do not work directly on the stuff we're developing but instead talk to the backend server that will follow the orders. WEB RUNNER CANVAS Instead of creating stacks with all their complexity, we would create something else that in the screen would appear like a stack, a floating window for the user to drop and arrange controls. What would be running in fact is a Rev coupled web server not unlike Ruby Web brick. This server would be running in the background and we would be seeing its output on this window inside the IDE. I have a Rev WebServer external ready for this project. Thats the second environment frame that I've mentioned above. It understands only Javascript. WEB SAFE TOOLS PALETTE & INSPECTOR Replacing the tools palette with a Web tailored one with tools that we've scripted ourselves. They can mimic standard Revolution tools such as buttons and fields but they are not in fact creating Revolution buttons and fields but our own controls. We would also create our own inspector for setting properties of our own self made controls. When we drag a control to the WEB RUNNER CANVAS, we don't actually do anything but talk to the underlining WEB SERVER saying we dropped such control, the server then will instantiate the control a place it for us. So in fact we're using Rev-like tools to talk to a web server that is building javascript on the fly for us. When we drop a button on the web runner screen, a POST call is made to the web server that picks this and creates a button javascript object, this is transparent to the developer. This way Rev becomes a HTML5/JS/CSS development tool. We don't have the overhead of converting stacks to web because we're jumping that whole step working directly with HTML5 and friends. This solves control placement and interaction but does not solve script processing. SCRIPT PROCESSING We would define a subset of RevTalk and create direct conversions from RevTalk to JS. As time went on we would implement more and more of RevTalk but some minimal subset should be enough for a start. Javascript is a wonderful language and converting scripts to it is the most safe option. Running the frontend logic in something like FastCGI adds to much processing to the server which adds to server load and to your costs. The elegance of this approach is that we can begin with a fastCGI engine for the script processing by directly executing RevTalk script on the FastCGI process without translation, this way we could place all the other pieces together before doing the RevTalk to JS work. By then we could simply put our efforts on that translation. We could build this and release under BSD license which would enable business to use it in the commercial offerings and thus making it attractive and incentive sponsorship. I would like to be paid to develop this free solution but I think it is now time for us to work on this or risk being left behind. This as it is defined needs no input whatsoever from the mothership, it can all be done in Rev. Any thoughts? -- http://www.andregarzia.com All We Do Is Code. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
