Aloha Friends, this is a very interesting project.
Let us think about our software using a simple generic model where no matter what our software does, it usually consists of Data + Some logic + Some UI. Right now, we can create server side revolution web application, so we solve the Data + Logic part, what we're missing is the UI part. We keep mixing logic in our user interface but, if we wanted, we could put all the logic into stack or card script and make all the UI just call those functions. We can put all that script into a server side component, what we can't do right now is convert Revolution Stack based UI to the web. We can't do this right now for two simple reasons: 1) Lack of volunteers. Stacks been converted to XML and SVG and even more... Mark made some experiments that converted stacks to HTML + CSS + JS. I've made a simple converter that could pick stacks based on just fields and buttons and convert them to XUL. So yes, we can make a tool to loop all the stack and convert the UI if we wanted. 2) Desktop applications != Web applications. Our apps are based on the following things: Stacks, Cards, Objects. The most popular objects being the button and the field. Web pages are nested objects which do not map back to our stacks/cards/objects. We're still to find a good way to build web user interfaces using revolution. So what path should we take? TileStack looks promissing but without seeing the development process, we can't really talk about it and better, what if we wanted to make Revolution work like TileStack? What we need is a good solid way to build web user interfaces in Rev, take notice that I am not talking about conversion, I am talking about building a web user interface that is from the start, coded to be used from the web. This solution should have the following motto: "convention over configuration", meaning that we should agree on some conventions such as Player objects become quicktime embed objects (or flash movies...) and then, developers building web apps from Rev would know that that player object would be converted into something else in the end. I don't know if any of you guys ever developed for the Apple Newton but one aspect that I found very interesting and inspiring was that the newton developers toolkit would run on macs and build software for the newton and when you wanted to build your UI, instead of having a WYSIWYG builder such as Rev, Delphi or VB, you had an empty canvas where you'd put simple rectangles, this rectangles had properties which said what they actually were. You build the interface in there without really seeing it. And it worked fine. In Rev, we could create something similar where we could draft our interfaces and interactions. As for the eternal CGI versus FastCGI, or single thread+multiple instances debate, we can solve everything with a simple thing. We can use simple CGI approach provided PERSISTANCE. What we need to solve is multiple revolution instances trying to access the same data, once a simple persistance library is made where one instance can set a customprop and some other can query it without trouble, then, our problems on the server are solved. by the way, anyone want to test the new RevOnRockets release? :-) andre _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
