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 use-revolution
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
Rev on Web?
You can make a Rev standalone and run it from the internet on Windows, no problem! Is there a way to do this on a Mac? Thanks, Dan ___ 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: Rev on Web?
On Apr 3, 2008, at 10:34 AM, Dan Friedman wrote: You can make a Rev standalone and run it from the internet on Windows, no problem! Is there a way to do this on a Mac? Dan, Can you explain more about what you mean by run it from the internet? There should be no difference between the way this works for Mac vs. Windows. The most common way to do this, Mac or Windows, is to create a small standalone that simply opens a stack that is stored on a web server with the command: go to stack URL http://myserver.domain.com/mystack.rev; If it's working for you in Windows but not in Mac, the most likely culprit is that the internet libraries are not being packaged with the standalone. In the standalone applications settings window, make sure that the Internet library is selected under Script libraries. (You'll have to Select Inclusions manually to be able to do this.) Let us know if it works out. Regards, Devin Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ 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: Rev on Web?
Devin, No, no... Not a stack, an application! Basically, we're replicating a web app with no install. On Windows, I can put http://www.mydomain.com/myapp.exe; in a web browser and run it (ya have to click run). Can you do something similar for the Mac - where no install is needed, or player. Thanks, -Dan Dan, Can you explain more about what you mean by run it from the internet? There should be no difference between the way this works for Mac vs. Windows. The most common way to do this, Mac or Windows, is to create a small standalone that simply opens a stack that is stored on a web server with the command: go to stack URL http://myserver.domain.com/mystack.rev; If it's working for you in Windows but not in Mac, the most likely culprit is that the internet libraries are not being packaged with the standalone. In the standalone applications settings window, make sure that the Internet library is selected under Script libraries. (You'll have to Select Inclusions manually to be able to do this.) Let us know if it works out. Regards, Devin Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ 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: Rev on Web?
On Apr 3, 2008, at 11:08 AM, Dan Friedman wrote: Devin, No, no... Not a stack, an application! Basically, we're replicating a web app with no install. On Windows, I can put http://www.mydomain.com/myapp.exe; in a web browser and run it (ya have to click run). Can you do something similar for the Mac - where no install is needed, or player. Ah, I understand now. There is no way I know of to do this on a Mac that I know of. You pretty much have to have a Rev engine running locally, which means an install would be required. Devin Dan, Can you explain more about what you mean by run it from the internet? There should be no difference between the way this works for Mac vs. Windows. The most common way to do this, Mac or Windows, is to create a small standalone that simply opens a stack that is stored on a web server with the command: go to stack URL http://myserver.domain.com/mystack.rev; If it's working for you in Windows but not in Mac, the most likely culprit is that the internet libraries are not being packaged with the standalone. In the standalone applications settings window, make sure that the Internet library is selected under Script libraries. (You'll have to Select Inclusions manually to be able to do this.) Let us know if it works out. Regards, Devin Devin Asay Humanities Technology and Research Support Center Brigham Young University Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ 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
Rev as Web Server CGI programming language?
Am trying to cut through the marketing chatter and understand the limitations of using RunRev for CGI work. Here is what I think I know, I'd appreciate corrections. Andre Garzia's RevHTTP stack is a really nice way to build a web based application in RunRev. You can use the debugger and you can store data in stacks and you can use the various installer apps to keep the web stack updated. It is single threaded such that when one connection comes in, no other connections can be processed until the current connection is done. Stack based - yes (build and troubleshoot on your desktop and copy to server) Apache server cgi - no Built-in web server - yes (IT folks are uncomfortable with standalone web servers) Debuggable - yes (you can have a connection go through the debugger on the server) Negligible launch and tear down overhead for each connection - yes (launch once and it is always running) Multiple connections - no Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (one stack) Global Variables that are specific to a single connection - yes (each connection can get setup with the initial connection globals) File based script version of Jacqueline Landman Gay's tutorial uses the traditional Apache CGI structure and RunRev as the backend process and as such, a new instance of the script gets created for each incoming connection. This is good for simultaneous multiple connections, but the text script version prevents using the RunRev debugger. Stack based - no Apache server cgi - yes (IT folks are comfortable managing Apache installations, it's a known knowledge set) Built-in web server - no Debuggable - no Negligible launch and tear down overhead for each connection - no (each script instance is fast to handle but with hundreds of connections per second, launch and tear down will become an issue) Multiple connections - yes (each connection spawns a new instance of the script) Multiple simultaneously processing connections - yes (the separate instances have no connections with each other and Apache handles the simultaneous processing) Global Variables that are global for all connections to the web service - yes (when stored in a common text file read at startup) Global Variables that are specific to a single connection - yes (the script can have setup variables at launch) The stack based version of Jacqueline Landman Gay's tutorial uses a simple file based script to execute scripts in stacks. This uses the traditional Apache CGI structure where a new incoming connection spawns a new instance of the script and that script interacts with a stack. This is where I am unsure. If the processing happens in stack scripts, how is contention handled when 100 script instances want to utilize the same stack? Do the scripts single thread one at a time to the stack? How is data stored in the stack by one connection handled by all the other connections? Stack based - yes Apache server cgi - yes Built-in web server - no Debuggable - yes Negligible launch and tear down overhead for each connection - no Multiple connections - yes Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (stored in the stack) Global Variables that are specific to a single connection - yes (because the stack can only be used by one connection at a time and the connection can reset the connection variables) What I'd like is the following. I want to build and debug using all the stack editing tools. I'm OK with single threading while I am debugging. But once I've debugged it, I want, for example, 100 simultaneous connections each running their copy of the stack, with each stack having access to shared data (Globals), but containing it's own data about it's connection (connection specific globals), and for these connections to stay up and be available for the next connection without the overhead of launching a fresh copy of the script or of the stack (high performance), oh and while I'm at it, if a stack is 2Mb in size and the data that I add to it is another 2Mb in size, can the memory footprint for additional connections be just the additional RAM needed for another set of data and not for another copy of the stack? Is there a way to get this using RunRev? Stack based - yes Apache server cgi - yes Built-in web server - no Debuggable - yes Negligible launch and tear down overhead for each connection - yes Multiple connections - yes Multiple simultaneously processing connections - yes Global Variables that are global for all connections to the web service - yes (stored in the stack) Global Variables that are specific to a single connection - yes (initialized by the CGI script before being fed to the stack) Is anyone doing a combo of Jacqueline's file and stack methods? Using the
Re: Rev as Web Server CGI programming language?
Kee, What I do here is this, I use the latest RevHTTP to build applications such as the ones on Jacques stack based tutorial. I debug and make sure it works in RevHTTP but I deploy on apache. The latest RevHTTP is able to run revolution CGI apps, no matter if they are file based or stack based. So I get the best of both worlds, easy debugging and testing from inside Rev and powerful serving from Apache. The trick is done by using my EasyCGI libraries. When run on RevHTTP, those library calls are overriden (can't. spell. english.) by RevHTTP so it all works together. The EasyCGI libraries make lots of things easy for they have functions for: communicating with the browser, session handling, rpc. The demos in RevHTTP package shows how to use everything. Nothing beats using breakpoints on web applications. Cheers andre On Apr 18, 2007, at 9:47 AM, kee nethery wrote: Am trying to cut through the marketing chatter and understand the limitations of using RunRev for CGI work. Here is what I think I know, I'd appreciate corrections. Andre Garzia's RevHTTP stack is a really nice way to build a web based application in RunRev. You can use the debugger and you can store data in stacks and you can use the various installer apps to keep the web stack updated. It is single threaded such that when one connection comes in, no other connections can be processed until the current connection is done. Stack based - yes (build and troubleshoot on your desktop and copy to server) Apache server cgi - no Built-in web server - yes (IT folks are uncomfortable with standalone web servers) Debuggable - yes (you can have a connection go through the debugger on the server) Negligible launch and tear down overhead for each connection - yes (launch once and it is always running) Multiple connections - no Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (one stack) Global Variables that are specific to a single connection - yes (each connection can get setup with the initial connection globals) File based script version of Jacqueline Landman Gay's tutorial uses the traditional Apache CGI structure and RunRev as the backend process and as such, a new instance of the script gets created for each incoming connection. This is good for simultaneous multiple connections, but the text script version prevents using the RunRev debugger. Stack based - no Apache server cgi - yes (IT folks are comfortable managing Apache installations, it's a known knowledge set) Built-in web server - no Debuggable - no Negligible launch and tear down overhead for each connection - no (each script instance is fast to handle but with hundreds of connections per second, launch and tear down will become an issue) Multiple connections - yes (each connection spawns a new instance of the script) Multiple simultaneously processing connections - yes (the separate instances have no connections with each other and Apache handles the simultaneous processing) Global Variables that are global for all connections to the web service - yes (when stored in a common text file read at startup) Global Variables that are specific to a single connection - yes (the script can have setup variables at launch) The stack based version of Jacqueline Landman Gay's tutorial uses a simple file based script to execute scripts in stacks. This uses the traditional Apache CGI structure where a new incoming connection spawns a new instance of the script and that script interacts with a stack. This is where I am unsure. If the processing happens in stack scripts, how is contention handled when 100 script instances want to utilize the same stack? Do the scripts single thread one at a time to the stack? How is data stored in the stack by one connection handled by all the other connections? Stack based - yes Apache server cgi - yes Built-in web server - no Debuggable - yes Negligible launch and tear down overhead for each connection - no Multiple connections - yes Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (stored in the stack) Global Variables that are specific to a single connection - yes (because the stack can only be used by one connection at a time and the connection can reset the connection variables) What I'd like is the following. I want to build and debug using all the stack editing tools. I'm OK with single threading while I am debugging. But once I've debugged it, I want, for example, 100 simultaneous connections each running their copy of the stack, with each stack having access to shared data (Globals), but containing it's own data about it's connection (connection specific globals), and for these connections to stay up and be available for the next connection without the overhead of launching a
Re: Rev as Web Server CGI programming language?
Hi Kee - Great blueprint! Thanks. Phil Davis kee nethery wrote: Am trying to cut through the marketing chatter and understand the limitations of using RunRev for CGI work. Here is what I think I know, I'd appreciate corrections. Andre Garzia's RevHTTP stack is a really nice way to build a web based application in RunRev. You can use the debugger and you can store data in stacks and you can use the various installer apps to keep the web stack updated. It is single threaded such that when one connection comes in, no other connections can be processed until the current connection is done. Stack based - yes (build and troubleshoot on your desktop and copy to server) Apache server cgi - no Built-in web server - yes (IT folks are uncomfortable with standalone web servers) Debuggable - yes (you can have a connection go through the debugger on the server) Negligible launch and tear down overhead for each connection - yes (launch once and it is always running) Multiple connections - no Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (one stack) Global Variables that are specific to a single connection - yes (each connection can get setup with the initial connection globals) File based script version of Jacqueline Landman Gay's tutorial uses the traditional Apache CGI structure and RunRev as the backend process and as such, a new instance of the script gets created for each incoming connection. This is good for simultaneous multiple connections, but the text script version prevents using the RunRev debugger. Stack based - no Apache server cgi - yes (IT folks are comfortable managing Apache installations, it's a known knowledge set) Built-in web server - no Debuggable - no Negligible launch and tear down overhead for each connection - no (each script instance is fast to handle but with hundreds of connections per second, launch and tear down will become an issue) Multiple connections - yes (each connection spawns a new instance of the script) Multiple simultaneously processing connections - yes (the separate instances have no connections with each other and Apache handles the simultaneous processing) Global Variables that are global for all connections to the web service - yes (when stored in a common text file read at startup) Global Variables that are specific to a single connection - yes (the script can have setup variables at launch) The stack based version of Jacqueline Landman Gay's tutorial uses a simple file based script to execute scripts in stacks. This uses the traditional Apache CGI structure where a new incoming connection spawns a new instance of the script and that script interacts with a stack. This is where I am unsure. If the processing happens in stack scripts, how is contention handled when 100 script instances want to utilize the same stack? Do the scripts single thread one at a time to the stack? How is data stored in the stack by one connection handled by all the other connections? Stack based - yes Apache server cgi - yes Built-in web server - no Debuggable - yes Negligible launch and tear down overhead for each connection - no Multiple connections - yes Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (stored in the stack) Global Variables that are specific to a single connection - yes (because the stack can only be used by one connection at a time and the connection can reset the connection variables) What I'd like is the following. I want to build and debug using all the stack editing tools. I'm OK with single threading while I am debugging. But once I've debugged it, I want, for example, 100 simultaneous connections each running their copy of the stack, with each stack having access to shared data (Globals), but containing it's own data about it's connection (connection specific globals), and for these connections to stay up and be available for the next connection without the overhead of launching a fresh copy of the script or of the stack (high performance), oh and while I'm at it, if a stack is 2Mb in size and the data that I add to it is another 2Mb in size, can the memory footprint for additional connections be just the additional RAM needed for another set of data and not for another copy of the stack? Is there a way to get this using RunRev? Stack based - yes Apache server cgi - yes Built-in web server - no Debuggable - yes Negligible launch and tear down overhead for each connection - yes Multiple connections - yes Multiple simultaneously processing connections - yes Global Variables that are global for all connections to the web service - yes (stored in the stack) Global Variables that are specific to a single connection - yes (initialized by the CGI script before being fed to the stack) Is anyone doing a combo of Jacqueline's file and stack
Re: Rev as Web Server CGI programming language?
Andre appears to do what I was pondering, write and debug using the stack based web server, and then deploy under apache in a text file. My plan is to try to document the development process so that I'll be able to remember how to use it months from now. When I get that documented I'll pass it back to the list. Looks like this is a good 95% of the solution I desire. And that should be good enough for now. Kee On Apr 18, 2007, at 7:42 AM, Phil Davis wrote: Hi Kee - Great blueprint! Thanks. Phil Davis kee nethery wrote: Am trying to cut through the marketing chatter and understand the limitations of using RunRev for CGI work. Here is what I think I know, I'd appreciate corrections. Andre Garzia's RevHTTP stack is a really nice way to build a web based application in RunRev. You can use the debugger and you can store data in stacks and you can use the various installer apps to keep the web stack updated. It is single threaded such that when one connection comes in, no other connections can be processed until the current connection is done. Stack based - yes (build and troubleshoot on your desktop and copy to server) Apache server cgi - no Built-in web server - yes (IT folks are uncomfortable with standalone web servers) Debuggable - yes (you can have a connection go through the debugger on the server) Negligible launch and tear down overhead for each connection - yes (launch once and it is always running) Multiple connections - no Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (one stack) Global Variables that are specific to a single connection - yes (each connection can get setup with the initial connection globals) File based script version of Jacqueline Landman Gay's tutorial uses the traditional Apache CGI structure and RunRev as the backend process and as such, a new instance of the script gets created for each incoming connection. This is good for simultaneous multiple connections, but the text script version prevents using the RunRev debugger. Stack based - no Apache server cgi - yes (IT folks are comfortable managing Apache installations, it's a known knowledge set) Built-in web server - no Debuggable - no Negligible launch and tear down overhead for each connection - no (each script instance is fast to handle but with hundreds of connections per second, launch and tear down will become an issue) Multiple connections - yes (each connection spawns a new instance of the script) Multiple simultaneously processing connections - yes (the separate instances have no connections with each other and Apache handles the simultaneous processing) Global Variables that are global for all connections to the web service - yes (when stored in a common text file read at startup) Global Variables that are specific to a single connection - yes (the script can have setup variables at launch) The stack based version of Jacqueline Landman Gay's tutorial uses a simple file based script to execute scripts in stacks. This uses the traditional Apache CGI structure where a new incoming connection spawns a new instance of the script and that script interacts with a stack. This is where I am unsure. If the processing happens in stack scripts, how is contention handled when 100 script instances want to utilize the same stack? Do the scripts single thread one at a time to the stack? How is data stored in the stack by one connection handled by all the other connections? Stack based - yes Apache server cgi - yes Built-in web server - no Debuggable - yes Negligible launch and tear down overhead for each connection - no Multiple connections - yes Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (stored in the stack) Global Variables that are specific to a single connection - yes (because the stack can only be used by one connection at a time and the connection can reset the connection variables) What I'd like is the following. I want to build and debug using all the stack editing tools. I'm OK with single threading while I am debugging. But once I've debugged it, I want, for example, 100 simultaneous connections each running their copy of the stack, with each stack having access to shared data (Globals), but containing it's own data about it's connection (connection specific globals), and for these connections to stay up and be available for the next connection without the overhead of launching a fresh copy of the script or of the stack (high performance), oh and while I'm at it, if a stack is 2Mb in size and the data that I add to it is another 2Mb in size, can the memory footprint for additional connections be just the additional RAM needed for another set of data and not for another copy of the stack? Is there a way to get this using RunRev?
Re: Rev as Web Server CGI programming language?
Kee, fetch http://andregarzia.com/RevHTTP.zip it has examples... Andre On Apr 18, 2007, at 1:42 PM, kee nethery wrote: Andre appears to do what I was pondering, write and debug using the stack based web server, and then deploy under apache in a text file. My plan is to try to document the development process so that I'll be able to remember how to use it months from now. When I get that documented I'll pass it back to the list. Looks like this is a good 95% of the solution I desire. And that should be good enough for now. Kee On Apr 18, 2007, at 7:42 AM, Phil Davis wrote: Hi Kee - Great blueprint! Thanks. Phil Davis kee nethery wrote: Am trying to cut through the marketing chatter and understand the limitations of using RunRev for CGI work. Here is what I think I know, I'd appreciate corrections. Andre Garzia's RevHTTP stack is a really nice way to build a web based application in RunRev. You can use the debugger and you can store data in stacks and you can use the various installer apps to keep the web stack updated. It is single threaded such that when one connection comes in, no other connections can be processed until the current connection is done. Stack based - yes (build and troubleshoot on your desktop and copy to server) Apache server cgi - no Built-in web server - yes (IT folks are uncomfortable with standalone web servers) Debuggable - yes (you can have a connection go through the debugger on the server) Negligible launch and tear down overhead for each connection - yes (launch once and it is always running) Multiple connections - no Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (one stack) Global Variables that are specific to a single connection - yes (each connection can get setup with the initial connection globals) File based script version of Jacqueline Landman Gay's tutorial uses the traditional Apache CGI structure and RunRev as the backend process and as such, a new instance of the script gets created for each incoming connection. This is good for simultaneous multiple connections, but the text script version prevents using the RunRev debugger. Stack based - no Apache server cgi - yes (IT folks are comfortable managing Apache installations, it's a known knowledge set) Built-in web server - no Debuggable - no Negligible launch and tear down overhead for each connection - no (each script instance is fast to handle but with hundreds of connections per second, launch and tear down will become an issue) Multiple connections - yes (each connection spawns a new instance of the script) Multiple simultaneously processing connections - yes (the separate instances have no connections with each other and Apache handles the simultaneous processing) Global Variables that are global for all connections to the web service - yes (when stored in a common text file read at startup) Global Variables that are specific to a single connection - yes (the script can have setup variables at launch) The stack based version of Jacqueline Landman Gay's tutorial uses a simple file based script to execute scripts in stacks. This uses the traditional Apache CGI structure where a new incoming connection spawns a new instance of the script and that script interacts with a stack. This is where I am unsure. If the processing happens in stack scripts, how is contention handled when 100 script instances want to utilize the same stack? Do the scripts single thread one at a time to the stack? How is data stored in the stack by one connection handled by all the other connections? Stack based - yes Apache server cgi - yes Built-in web server - no Debuggable - yes Negligible launch and tear down overhead for each connection - no Multiple connections - yes Multiple simultaneously processing connections - no Global Variables that are global for all connections to the web service - yes (stored in the stack) Global Variables that are specific to a single connection - yes (because the stack can only be used by one connection at a time and the connection can reset the connection variables) What I'd like is the following. I want to build and debug using all the stack editing tools. I'm OK with single threading while I am debugging. But once I've debugged it, I want, for example, 100 simultaneous connections each running their copy of the stack, with each stack having access to shared data (Globals), but containing it's own data about it's connection (connection specific globals), and for these connections to stay up and be available for the next connection without the overhead of launching a fresh copy of the script or of the stack (high performance), oh and while I'm at it, if a stack is 2Mb in size and the data that I add to it is another 2Mb in size, can the memory footprint for additional connections be just the
Re: Rev as Web Server CGI programming language?
Kee, I'm pretty sure that what happens is that each connection spawns an instance not just of the initial text script, but of the rev CGI engine, and therefore also whatever stacks (each instance of) it loads into memory. The propblem, as you have suggested, is what happens when 100 separate processes all try to save the stack to the same stackfile at the same time. I don't know, but maybe an environment variable could be set when saving, and cleared when finished, so each process could check on whether it's safe to save by looking at the envirionment varaiable, and waiting til it's clear before saving. Or maybe, depending on the needs of the application, data could be saved in separate text files for each process. Best, Mark On 18 Apr 2007, at 13:47, kee nethery wrote: If the processing happens in stack scripts, how is contention handled when 100 script instances want to utilize the same stack? Do the scripts single thread one at a time to the stack? How is data stored in the stack by one connection handled by all the other connections? ___ 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: Rev as Web Server CGI programming language?
Kee, fetch http://andregarzia.com/RevHTTP.zip it has examples... Andre Pierre Sahores advocated an approach of coupling a Rev-based cgi-type but resident program with Apache through sockets. He was using this solution for massive online services. However, the link to his page no longer works. Does anyone have those materials? Robert Brenstein ___ 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: Rev as Web Server CGI programming language?
Not on hand, but I know Pierre has posted the source code a few times to the list. I would try searching the archives for his name plus PHP and sockets. Keep in mind you still get the single-threaded lock at the stack level, but sticking PHP in between does give you the ability to juggle connections while Rev works on one request at a time. Pierre had some pretty good results with this. - Brian fetch http://andregarzia.com/RevHTTP.zip it has examples... Andre Pierre Sahores advocated an approach of coupling a Rev-based cgi- type but resident program with Apache through sockets. He was using this solution for massive online services. However, the link to his page no longer works. Does anyone have those materials? Robert Brenstein ___ 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 ___ 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: Rev as Web Server CGI programming language?
Not on hand, but I know Pierre has posted the source code a few times to the list. I would try searching the archives for his name plus PHP and sockets. Keep in mind you still get the single-threaded lock at the stack level, but sticking PHP in between does give you the ability to juggle connections while Rev works on one request at a time. Pierre had some pretty good results with this. - Brian I searched the archives but haven't hit anything specific. Pierre posted to the list a lot and most of his rev-as-cgi includes references to the non-working page. The best hits I got are: http://revstudio.runrev.com/section/case_studies/sockets.php http://www.mail-archive.com/use-revolution@lists.runrev.com/msg86008.html http://www.nabble.com/Re:-rev-sockets-driven-apps...-t1335157.html Robert ___ 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
Rev related web pages
Hi everyone, Among the plugins I have in the works, one of them will allow the user to search info on the web when programming. Several methods will be used for searching the mailing lists, RevOnLine, the whole web with an engine or another, etc. Another one will work through a customizable index the user will be able to modify as she/he wishes. At the moment, the provided basis index references the following web pages. I surely forgot some valuable Rev related pages (where a search by keywords in the text is relevant). Could you help me to complete this list? Thanks. http://dark.unitz.ca/~shaosean/pages/development.htm http://geocities.com/capellan2000/ http://home.infostations.net/jhurley/ http://homepage.mac.com/WebObjects/FileSharing.woa/wa/default? user=soapdogtemplatefn=FileSharing12.htmlxmlfn=TKDocument.12.xmlsitef n=RootSite.xmlaff=consumercty=USlang=en http://mangomultimedia.com/developer/revolution/ http://mindlube.com/developer/ http://revolutionboard.de/bvg/subindexes/stacks-2.html http://rinaldicollection.free.fr/frevplugins_frame.htm http://www.altuit.com/webs/altuit2/altPluginDownload/Downloads.htm http://www.altuit.com/webs/altuit2/RunRev/Downloads.htm http://www.flexiblelearning.com/xtalk.htm http://www.fourthworld.com/rev/index.html http://www.geocities.com/janschenkel/ http://www.hyperactivesw.com/Resources.html http://www.inspiredlogic.com/downloads.html http://www.major-k.de/revstart.html http://www.monsieurx.com/modules.php? name=Newsnew_topic=17min=0query=%20type=stories http://www.sanke.org/MetaMedia/SamplesTools.htm http://www.sonsothunder.com/devres/revolution/revolution.htm http://www.sosmartsoftware.com/?r=revolutionl=en http://www.swcp.com/dsc/revstacks.html http://www.sweattechnologies.com/rev/ http://www.tactilemedia.com/download/ http://www.troz.net/Rev/ Best regards, Eric Chatonet. So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Web sitehttp://www.sosmartsoftware.com/ Email [EMAIL PROTECTED]/ Phone 33 (0)1 43 31 77 62 Mobile 33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rev related web pages
Excellent Eric! You can find most of the Rev related webs via the RunRev extenals links (but it's not easy to find and seems less complete than the previous webpage which I didn't find this time - and it still doesn't have my website!!!) or MonsieurX's weblinks which are usually up to date and comprehensive with most links. Sorry If i forgot anyone's website, just let me know or submit it via MonsieurX.. There's some 30 links in total as far as I know... cheers Xavier On 15.04.2005 10:38:44 use-revolution-bounces wrote: Hi everyone, Among the plugins I have in the works, one of them will allow the user to search info on the web when programming. Several methods will be used for searching the mailing lists, RevOnLine, the whole web with an engine or another, etc. Another one will work through a customizable index the user will be able to modify as she/he wishes. At the moment, the provided basis index references the following web pages. I surely forgot some valuable Rev related pages (where a search by keywords in the text is relevant). Could you help me to complete this list? Thanks. http://dark.unitz.ca/~shaosean/pages/development.htm http://geocities.com/capellan2000/ http://home.infostations.net/jhurley/ http://homepage.mac.com/WebObjects/FileSharing.woa/wa/default? user=soapdogtemplatefn=FileSharing12.htmlxmlfn=TKDocument.12.xmlsitef n=RootSite.xmlaff=consumercty=USlang=en http://mangomultimedia.com/developer/revolution/ http://mindlube.com/developer/ http://revolutionboard.de/bvg/subindexes/stacks-2.html http://rinaldicollection.free.fr/frevplugins_frame.htm http://www.altuit.com/webs/altuit2/altPluginDownload/Downloads.htm http://www.altuit.com/webs/altuit2/RunRev/Downloads.htm http://www.flexiblelearning.com/xtalk.htm http://www.fourthworld.com/rev/index.html http://www.geocities.com/janschenkel/ http://www.hyperactivesw.com/Resources.html http://www.inspiredlogic.com/downloads.html http://www.major-k.de/revstart.html http://www.monsieurx.com/modules.php? name=Newsnew_topic=17min=0query=%20type=stories http://www.sanke.org/MetaMedia/SamplesTools.htm http://www.sonsothunder.com/devres/revolution/revolution.htm http://www.sosmartsoftware.com/?r=revolutionl=en http://www.swcp.com/dsc/revstacks.html http://www.sweattechnologies.com/rev/ http://www.tactilemedia.com/download/ http://www.troz.net/Rev/ Best regards, Eric Chatonet. So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Web site http://www.sosmartsoftware.com/ Email [EMAIL PROTECTED]/ Phone 33 (0)1 43 31 77 62 Mobile 33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution - Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rev related web pages
On Apr 15, 2005, at 5:38 AM, Eric Chatonet wrote: http://homepage.mac.com/WebObjects/FileSharing.woa/wa/default? user=soapdogtemplatefn=FileSharing12.htmlxmlfn=TKDocument.12.xmlsite fn=RootSite.xmlaff=consumercty=USlang=en Eric, Thanks for compiling this list but this link is not my root folder, you'd better link to http://www.soapdog.org that link you used is unstable and does not contain the latest releases. cheers Andre -- Andre Alves Garzia 2004 BRAZIL http://studio.soapdog.org ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rev related web pages
Hi Andre, I understand correctly yours reasons but the problem is the following: When you add a web page reference, the plugin put the text from this page into its local database. Then this database will be searched for keywords specified by the user. So, with your main addess, I wonder what keywords would be found :-) Have you another web page with such keywords as chat, libWrapper and so on which would have a link to your downloads page? Best, Le 15 avr. 05, à 15:37, Andre Garzia a écrit : On Apr 15, 2005, at 5:38 AM, Eric Chatonet wrote: http://homepage.mac.com/WebObjects/FileSharing.woa/wa/default? user=soapdogtemplatefn=FileSharing12.htmlxmlfn=TKDocument.12.xmlsit efn=RootSite.xmlaff=consumercty=USlang=en Eric, Thanks for compiling this list but this link is not my root folder, you'd better link to http://www.soapdog.org that link you used is unstable and does not contain the latest releases. cheers Andre Eric Chatonet. So Smart Software Pour les institutionnels, les entreprises et les associations Des logiciels sur mesure : gestion, multimédia, internet, etc. Windows, Mac OS et Linux... Avec la french touch For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Web sitehttp://www.sosmartsoftware.com/ Email [EMAIL PROTECTED]/ Phone 33 (0)1 43 31 77 62 Mobile 33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rev related web pages
This thread seems like a good time for your quarterly reminder about Open Directory and VersionTracker: Open Directory -- There's a page for Transcript in Open Directory: http://dmoz.org/Computers/Programming/Languages/Transcript/ Open Directory (aka DMOZ) is the world's largest hand-edited directory, syndicated at thousands of other sites and helps feed Google, Inktomi, and most other major search engines. If you have a web page related to Revolution please add it to that page -- there' a suggest URL link at the top. It only takes a minute to do, and helps ensure that Open Directory will be not only the most popular listing of Rev stuff, but also the most complete. Of the many dozens of Rev sites I come across, so far only 19 are listed in Open Directory. VersionTracker -- VersionTracker is one of the most popular sites for downloading new software. Unlike a lot of their competitors, VersionTracker remains completely free for developers to list their stuff, and they allow submissions of plugins and add-ons for any product they have listed there, including Revolution. You can see the Rev stuff already posted by searching for revolution -- here it is for the Windows section: http://www.versiontracker.com/php/search.php?mode=basicaction=searchstr=revolutionplt%5B%5D=windowsx=0y=0 And for OS X: http://www.versiontracker.com/php/search.php?PHPSESSID=72023eb980a8abbc9d30fc7dace8548fmode=basicaction=searchstr=revolutionplt%5B%5D=macosxx=0y=0 Getting set up as a developer there takes only a couple minutes, and it easy to do -- start here: http://www.versiontracker.com/developer/login.php If you have any questions they have a friendly and helpful staff who have been very responsive the few times I've ever needed to contact them. Taking advantage of these resources will not only help your work reach more people, but it also reflects well on RunRev by showing the world the true size of the large and growing community of Revolution developers. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: using Rev for web searches?
Martin- Saturday, March 12, 2005, 2:06:32 PM, you wrote: It may be worth offering a gentle reminder here to always follow the guidelines Google provides for using their API: http://www.google.com/apis/ MB Fair enough as a general statement, but in the particular case of the MB Google API, to use it you need your own API developer key, and Google MB itself limits the number of queries each key can do in a day and the number MB of results you get. If you did that from RR, it shouldn't affect Revolution More to the point, the Google API Terms of Service agreement specifically forbids reformatting and metasearches, which in itself invalidates most of code in the Google hacks book. While a Google license sounds like a good idea in order to do the Right Thing, the encumberances actually make doing anything with the returned results impossible. ...but then, of course, if I followed the letter of every EULA I've had to sign off on, I'd never touch my keyboard... -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: using Rev for web searches?
There's a book out there about how to 'hack' and use google searches from your applications with the new API. 101 Google hacks or something like that. http://www.oreilly.com/catalog/googlehks/ I'd like to be able to search the web for the smallest page that includes all of a given set of words. Does anybody know of a way to do this? This is an interesting question, but there's one that has to be answered before you can even attempt to ask this question: Is there a complete index of every type of document available on the web? Now if being 100% accurate doesn't matter, then sure. Do a search for all of the words. Take the results and go through them one by one and compare the sizes. You should have the answer then, and all of it can easily be done with a script. Derek Bump Dreamscape Software ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: using Rev for web searches?
Stephen Barncard wrote: I'd like to be able to search the web for the smallest page that includes all of a given set of words. Does anybody know of a way to do this? This is an interesting question, but there's one that has to be answered before you can even attempt to ask this question: Is there a complete index of every type of document available on the web? Now if being 100% accurate doesn't matter, then sure. Do a search for all of the words. Take the results and go through them one by one and compare the sizes. You should have the answer then, and all of it can easily be done with a script. There's a book out there about how to 'hack' and use google searches from your applications with the new API. 101 Google hacks or something like that. http://www.oreilly.com/catalog/googlehks/ It may be worth offering a gentle reminder here to always follow the guidelines Google provides for using their API: http://www.google.com/apis/ It's in the interest of all Rev developers that search tools, bots, and anything else that carries the Revolution USER-AGENT tag be seen a good citizen. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: using Rev for web searches?
Nicolas- Friday, March 11, 2005, 7:44:16 PM, you wrote: NC I'd like to be able to search the web for the smallest page that includes NC all of a given set of words. Does anybody know of a way to do this? I think you'd need to define smallest page... is this the least amount of displayed text, the smallest raw text, or something else? That said, this is similar to what I'm doing in my ArchiveSearch plugin: handing off search arguments to Google and data-mining the results. There's too much code to paste inline here, but if you're interested, take a look at the mouseUp script in button btnSearch of the stack. Parsing through the returned info, though, could be anything but simple. http://www.ahsoftware.net/ArchiveSearch.html -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: using Rev for web searches?
Stephen Barncard wrote: I'd like to be able to search the web for the smallest page that includes all of a given set of words. Does anybody know of a way to do this? This is an interesting question, but there's one that has to be answered before you can even attempt to ask this question: Is there a complete index of every type of document available on the web? Now if being 100% accurate doesn't matter, then sure. Do a search for all of the words. Take the results and go through them one by one and compare the sizes. You should have the answer then, and all of it can easily be done with a script. There's a book out there about how to 'hack' and use google searches from your applications with the new API. 101 Google hacks or something like that. http://www.oreilly.com/catalog/googlehks/ It may be worth offering a gentle reminder here to always follow the guidelines Google provides for using their API: http://www.google.com/apis/ It's in the interest of all Rev developers that search tools, bots, and anything else that carries the Revolution USER-AGENT tag be seen a good citizen. -- Richard Gaskin Fair enough as a general statement, but in the particular case of the Google API, to use it you need your own API developer key, and Google itself limits the number of queries each key can do in a day and the number of results you get. If you did that from RR, it shouldn't affect Revolution any more than Running such queries from User-Agent MSIE affects Microsoft, surely, or am I wrong? The point of the Google API is to provide a legal method of search automation, preferable from Google's viewpoint to all and sundry bombarding the regular search engine with automated queries. Interfaces to the API, such as one might build in RR, almost always require the end-user to use their own developer key. Don't let the Google Hacks book title mislead you, it's only an eye-catching title for a chatty review of stuff you can do with the Google API and a few related topics of ineterest, and very little in it would really qualify as a Hack, it was after all written with input from Google. Martin Baxter ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
using Rev for web searches?
Hello All, A teaching colleague who shares my interest in corpus linguistics posed the following question, which I thought might have a (simple?) Rev-based solution: I'd like to be able to search the web for the smallest page that includes all of a given set of words. Does anybody know of a way to do this? I ask here cause these last few weeks I seem to recall Google and web-searches as one of the topics, so I thought a knowledgeable someone might have a suggestion (or two!). Thanks. Cheers, Nicolas Cueto niconiko language school ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: using Rev for web searches?
I'd like to be able to search the web for the smallest page that includes all of a given set of words. Does anybody know of a way to do this? This is an interesting question, but there's one that has to be answered before you can even attempt to ask this question: Is there a complete index of every type of document available on the web? Now if being 100% accurate doesn't matter, then sure. Do a search for all of the words. Take the results and go through them one by one and compare the sizes. You should have the answer then, and all of it can easily be done with a script. Derek Bump Dreamscape Software ___ Compress Images Easily with JPEGCompress 2.5 http://www.dreamscapesoftware.com/ ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
