Re: [FOSS] On the creation of Rev to Web tools
Andre, This all sounds phantastic ! Great idea ! I don't know if I can help, but I will if I can ! Please keep us up to date on this ! Cheers Rolf ___ 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
[FOSS] On the creation of Rev to Web tools
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
Re: [FOSS] On the creation of Rev to Web tools
Andre, sorry for hijacking this thread a bit... I would be interested in how many people would really think they would be willing to invest some effort into various open source projects. I know David is a huge advocate of all things OSS. However, as Richmond pointed out pretty well, over the last 8 years I´ve spend in this community I have rarely seen OSS projects that took up momentum. I have been wondering why that is for quite a while now. My main thought is that it is not exactly easy to collaborate on rev Projects. This is partly due to the binary nature of stacks which makes it hard to use a version control system on rev projects, partly due to the lack of a place where projects like this could be hosted. Current state: Everyone that tries to release stuff to the community is cooking her own soup. Though most people are very generous with sharing code on the lists and forums, there is no central repository where people can go to and collaborate on projects. We do have many sites spread all over the world with too many gems to dig out. Additionally we have revOnline. revOnline is a good place for consumers / prosumers though, not suitable for starting a collaborative effort to work on code. Especially libraries. Most of the stuff on revOnline is there for the visual stuff the stack does, or in a state where the lib is basically finished. So the only things an author that uploads to revOnline can gain is - giving examples what can be done - help someone solve a problem with a complex stuff (requires a lot of coordination and is usually easier done by mail) - show off what he has done. What an author usually can not hope for is to benefit from changes other coders have made once a stack is released into the wild. I have no idea how many people here would really willing to dedicate time into OSS projects (my last try was rather frustrating, though it has been a few years since I last tried.) I might be willing to test the waters again in a couple of weeks. More on that later. All the best, Malte ___ 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
Re: [FOSS] On the creation of Rev to Web tools
On 15 September 2010 16:10, Malte Pfaff-Brill revolut...@derbrill.dewrote: I would be interested in how many people would really think they would be willing to invest some effort into various open source projects. I know David is a huge advocate of all things OSS. However, as Richmond pointed out pretty well, over the last 8 years I´ve spend in this community I have rarely seen OSS projects that took up momentum. I have been wondering why that is for quite a while now. My main thought is that it is not exactly easy to collaborate on rev Projects. It's mainly due to the economics of cooperating in Rev - too easy to develop solo, and partly due to the history of the community - it's average age is pre-open source / more share ware - so the culture is not there, and finally the community is a little small. For these reasons you need to do a little bit more than simply than place code up on server and declare it open under some undetermined license for a project to take off. This is partly due to the binary nature of stacks which makes it hard to use a version control system on rev projects, partly due to the lack of a place where projects like this could be hosted. The version control problem, is effectively solved now that we can create objects with IDs. It's a red herring anyway, as the majority of useful code can be shared under version control without problem. Current state: Everyone that tries to release stuff to the community is cooking her own soup. Though most people are very generous with sharing code on the lists and forums, there is no central repository where people can go to and collaborate on projects. We do have many sites spread all over the world with too many gems to dig out. Additionally we have revOnline. revOnline is a good place for consumers / prosumers though, not suitable for starting a collaborative effort to work on code. Especially libraries. Most of the stuff on revOnline is there for the visual stuff the stack does, or in a state where the lib is basically finished. So the only things an author that uploads to revOnline can gain is - giving examples what can be done - help someone solve a problem with a complex stuff (requires a lot of coordination and is usually easier done by mail) - show off what he has done. RevOnline does not work - it is not a collaborative environment, which is why it is easier for people to post urls to downloadable stacks than indicate there is a stack on revOnline. It should be replaced. What an author usually can not hope for is to benefit from changes other coders have made once a stack is released into the wild. I have no idea how many people here would really willing to dedicate time into OSS projects (my last try was rather frustrating, though it has been a few years since I last tried.) I might be willing to test the waters again in a couple of weeks. More on that later. Not many. They would when it works. The hard part is not the many, its the first 5. Ever tried to herd cats? Well there aren't any cats in the Rev community - they are wolves. They growl a lot and are fiercely independent, but are deep down secret pack animals even though they wont admit it in public :) The mothership has a lot to answer for. ___ 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
Re: [FOSS] On the creation of Rev to Web tools
Hi Malte, I too have pondered the question. I ended up feeling that the buy in required by the commercial nature of the main product limits uptake by young blood (generally poor) in numbers necessary to create open source momentum. I have watched Ruby go from zero to being on the radar in the interim, and few up and comers are going to latch onto runrev/livecode in the same way. The no cost versions of the product are limited by commercial necessity and those limits will always weigh on the balance of youngsters choosing between the full package in a free language/IDE versus a reduced package here. It seems a by-product of the necessity of RunRev/Kevin/Markula/unknown ownership interests et al. needing to earn a return on their investment. I have been discouraged in concluding that while the base may grow it probably can never capture the explosive exponential growth phase that the truly successful open source languages have that only come with a couple orders of magnitude of extra sets of eyeballs in the mix. The product remains a wonderful secret weapon but will always languish behind the frontier of the evolving landscape. I really wish that a wealthy benefactor like Bill Gates would buy the whole thing and release it all and let a thousand variations bloom and weed themselves out... Until it is absolutely no cost for the full version you simply won't get teens on board in number, the ones with unlimited time and no commercial obligations, and otaku like devotion to tackle the next new thing... ___ 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
Re: [FOSS] On the creation of Rev to Web tools
Malte, Is my firm belief that if the project will save or make people money right away then they will help... :D On Wed, Sep 15, 2010 at 12:10 PM, Malte Pfaff-Brill revolut...@derbrill.dewrote: Andre, sorry for hijacking this thread a bit... I would be interested in how many people would really think they would be willing to invest some effort into various open source projects. I know David is a huge advocate of all things OSS. However, as Richmond pointed out pretty well, over the last 8 years I´ve spend in this community I have rarely seen OSS projects that took up momentum. I have been wondering why that is for quite a while now. My main thought is that it is not exactly easy to collaborate on rev Projects. This is partly due to the binary nature of stacks which makes it hard to use a version control system on rev projects, partly due to the lack of a place where projects like this could be hosted. Current state: Everyone that tries to release stuff to the community is cooking her own soup. Though most people are very generous with sharing code on the lists and forums, there is no central repository where people can go to and collaborate on projects. We do have many sites spread all over the world with too many gems to dig out. Additionally we have revOnline. revOnline is a good place for consumers / prosumers though, not suitable for starting a collaborative effort to work on code. Especially libraries. Most of the stuff on revOnline is there for the visual stuff the stack does, or in a state where the lib is basically finished. So the only things an author that uploads to revOnline can gain is - giving examples what can be done - help someone solve a problem with a complex stuff (requires a lot of coordination and is usually easier done by mail) - show off what he has done. What an author usually can not hope for is to benefit from changes other coders have made once a stack is released into the wild. I have no idea how many people here would really willing to dedicate time into OSS projects (my last try was rather frustrating, though it has been a few years since I last tried.) I might be willing to test the waters again in a couple of weeks. More on that later. All the best, Malte ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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
Re: [FOSS] On the creation of Rev to Web tools
there goes my thread :-( On Wed, Sep 15, 2010 at 12:27 PM, wayne durden wdur...@gmail.com wrote: Hi Malte, I too have pondered the question. I ended up feeling that the buy in required by the commercial nature of the main product limits uptake by young blood (generally poor) in numbers necessary to create open source momentum. I have watched Ruby go from zero to being on the radar in the interim, and few up and comers are going to latch onto runrev/livecode in the same way. The no cost versions of the product are limited by commercial necessity and those limits will always weigh on the balance of youngsters choosing between the full package in a free language/IDE versus a reduced package here. It seems a by-product of the necessity of RunRev/Kevin/Markula/unknown ownership interests et al. needing to earn a return on their investment. I have been discouraged in concluding that while the base may grow it probably can never capture the explosive exponential growth phase that the truly successful open source languages have that only come with a couple orders of magnitude of extra sets of eyeballs in the mix. The product remains a wonderful secret weapon but will always languish behind the frontier of the evolving landscape. I really wish that a wealthy benefactor like Bill Gates would buy the whole thing and release it all and let a thousand variations bloom and weed themselves out... Until it is absolutely no cost for the full version you simply won't get teens on board in number, the ones with unlimited time and no commercial obligations, and otaku like devotion to tackle the next new thing... ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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
Re: [FOSS] On the creation of Rev to Web tools
On 15 September 2010 15:31, Andre Garzia an...@andregarzia.com wrote: 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. Agreed that would be hard short term, and probably doomed to fail long term. TWO ENVIRONMENT FRAMES ... 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 ... I have a Rev WebServer external ready for this project. Thats the second environment frame that I've mentioned above. It understands only Javascript. I don't see any need for this approach? perhaps you need to explain a bit more. What is wrong with getting the RevIDE to do all this client side? The only reason to do this server side that I can see is to build a business case around it. The RevIDe can do all this at lower cost - bandwidth etc, and there are no real maintenance issues with distributed rev tools nowadays. Don't get this. 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. I think this is almost right, except that the logic of replicating Rev controls is the wrong way round. Frankly the web controls are out of date, and less sophisticated no than those you find in JavaScript libraries. Also the audience and market is larger for people familiar with these existing JavaScript interfaces than the tiny Rev market. What is needed is to emulate the best and most robust JavaScript controls with Rev widgets - not the other way round. ... 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. Again I can see absolutely no reason for the web server to do this - it's more work, and what is the benefit? The dragging components onto the canvas, can be done in the IDE. I demoed this at the last conference with widgets that are under version control on the server. 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. In MVC terms (as you say) - the controllers and models can be on the server. This server side code could be on On-Rev, but equally there is no reason when any good robust server code could be used in any language, we just need to wrap so that the RevTalk based IDE handles it for us in the background. As an aside, the code I've been working on is based around the idea that we can have a more robust Rev based workflow (which speeds up native Rev development), and has the side effect of producing server based controller code - that can be ftp'd / transferred to the server and work there in exactly the same way as it does locally. The aim is to enable the sharing of this portable abstracted code, and build it into intuitive workflows so that it is generated in a natural way as part of coding in Rev. 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. Yes - I think we are on the same page here. I see a sub-category of shared code, which could be translated into JavaScript or other languages. People would do this in order to allow their projects to work with existing online frameworks, while allowing local prototyping in RevTalk. The workflow is natural, and allows for gradual evolution of code bases based on incremental incentives that benefit the end user. I think it could work, especially if it were part of an explicit open source / open content strategy by RunRev, in which they took and supportive but indirect role. 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 I still don't see any advantage to this - maybe I am missing something? And FastCGI is AFAIK not the way to go now anyway? 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. This as it is defined needs no input whatsoever from the mothership, it can all be done in Rev. It does not need
Re: [FOSS] On the creation of Rev to Web tools
David, I think I was misunderstood on the two environment part. When I say web server and Rev IDE I am not saying remote web server in the sense of a server far away but a little process running alongside the IDE on the same machine. Not unlike the mongrel/ruby coupling. You'll be working all on client side. No wasted bandwidth or extra CPU power required. You need, in my opinion, the server running to be able to develop in an environment that is equal to your deployment option so that you don't end up with cycles such as: 1 - build stuff in Rev 2 - convert it to web 3 - run it and it does not work or does not layout right 4 - back to Rev If you're constantly building and tweeking inside a HTML5 enabled window, you get the following benefits: 1 - You avoid any conversion need since you are already on the deployed environment 2 - WYSIWYG approach, what you see on the canvas is exactly what the client will see, no need to compile or translate anything This way we maintain one of the strongest features of Rev which is being able to develop incrementally avoiding the overhead of compile-debug-code loops. So in summary: 1 - the server is there because we need something to output as real-as-possible data to a RevBrowser window inside Rev IDE where the development will be done. ___ 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
Re: [FOSS] On the creation of Rev to Web tools
Aha - got you. Good plan for offline development - though secondary in terms of priority I'd say to having remote server based solution? NB - is the external based on one of the C based open source server projects? On 15 September 2010 17:19, Andre Garzia an...@andregarzia.com wrote: David, I think I was misunderstood on the two environment part. When I say web server and Rev IDE I am not saying remote web server in the sense of a server far away but a little process running alongside the IDE on the same machine. Not unlike the mongrel/ruby coupling. You'll be working all on client side. No wasted bandwidth or extra CPU power required. You need, in my opinion, the server running to be able to develop in an environment that is equal to your deployment option so that you don't end up with cycles such as: 1 - build stuff in Rev 2 - convert it to web 3 - run it and it does not work or does not layout right 4 - back to Rev If you're constantly building and tweeking inside a HTML5 enabled window, you get the following benefits: 1 - You avoid any conversion need since you are already on the deployed environment 2 - WYSIWYG approach, what you see on the canvas is exactly what the client will see, no need to compile or translate anything This way we maintain one of the strongest features of Rev which is being able to develop incrementally avoiding the overhead of compile-debug-code loops. So in summary: 1 - the server is there because we need something to output as real-as-possible data to a RevBrowser window inside Rev IDE where the development will be done. ___ 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
Re: [FOSS] On the creation of Rev to Web tools
On Wed, Sep 15, 2010 at 5:15 PM, David Bovill da...@vaudevillecourt.tvwrote: Aha - got you. Good plan for offline development - though secondary in terms of priority I'd say to having remote server based solution? NB - is the external based on one of the C based open source server projects? The external is based on mongoose. On 15 September 2010 17:19, Andre Garzia an...@andregarzia.com wrote: David, I think I was misunderstood on the two environment part. When I say web server and Rev IDE I am not saying remote web server in the sense of a server far away but a little process running alongside the IDE on the same machine. Not unlike the mongrel/ruby coupling. You'll be working all on client side. No wasted bandwidth or extra CPU power required. You need, in my opinion, the server running to be able to develop in an environment that is equal to your deployment option so that you don't end up with cycles such as: 1 - build stuff in Rev 2 - convert it to web 3 - run it and it does not work or does not layout right 4 - back to Rev If you're constantly building and tweeking inside a HTML5 enabled window, you get the following benefits: 1 - You avoid any conversion need since you are already on the deployed environment 2 - WYSIWYG approach, what you see on the canvas is exactly what the client will see, no need to compile or translate anything This way we maintain one of the strongest features of Rev which is being able to develop incrementally avoiding the overhead of compile-debug-code loops. So in summary: 1 - the server is there because we need something to output as real-as-possible data to a RevBrowser window inside Rev IDE where the development will be done. ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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
