I read somewhere months ago about RunRev intended to develop a server-side module (like apache mod) for xTalk scripting.
It should be similar to how PHP mod works.
Anyone?
While I've been enjoyed using the CGI "glue" for many years, I have trouble to recommend it or even upscaling it when projects get more complicated and growing on the usage.
PHP runs 100 times more efficiently as apache module instead of CGI.
I expect RunRev should offer great efficiency if they offer some kind of apache mod too - or even something for us to glue with FastCGI would be nice - the need for starting the runrev engine on every click on the browser is really killing.
I honestly wish to see this to become true.
It is rather important for our web application behind the scene: we either have to pick up Java (or PHP) now to accommodate our growth in the next 5 years, or stick with RunRev CGI and upgrade to RunRev mod when they are available.
--
RunRev developing PHP alike server-side xTalk module?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
I do believe you are correct in that there will be some kind of apache module that will allow Revolution to be used as a scripting language. I have no idea when it will be released, but probably some time in 2009. In the interim (or if you would prefer to wait until any bugs in this new option to be removed), there is a technique developed by Pierre Sahores and the original designer of the engine behind Revolution (Scott Raney), which uses PHP has a conduit to a long-running Revolution process. This system has been in use in French government sites for some years, and as I understand it, with very good response times.
Good ol' Pierre has even gone to the trouble of writing a tutorial, and sample code:
http://www2.sahores-conseil.com/insead/index_en.html
Good ol' Pierre has even gone to the trouble of writing a tutorial, and sample code:
http://www2.sahores-conseil.com/insead/index_en.html
While I admired all these effort to make long-running Revolution process possible at the server, the implementation has a few flaws:
1. MetaCard/Revolution built-in TCP/IP server socket used to listen to incoming traffic. The socket command in revolution is very robust to use as a "client", not really reliable as server. We have attempted this a few times in the pass, unfortunately we have to restart the process couple of time a day, even with pretty light traffic (few thousand hits). Although this could be partly due to our bad programming, turning it into executable script behind xinetd seems to solve the problem - but that basically back to CGI implementation similar to apache.
2. The process isn't really multi-threaded. Although the event based socket command provide some kind of schedule and distributed execution environment, a badly coded handle can hog the entire process down, and queue up the subsequent hits.
3. Increase the complexity on coding. We have to "release" the process cycle in a CPU intensive task by doing "wait x milliseconds with messages" in order to ensure other handle get the turn on execution. Unfortunately, this is not always possible as the task can be unpredictable in certain conditions, like waiting for a complex database query to come back etc.
4. Memory leaks. I don't know about others, it seems to me there is definitely some memory leaks somewhere in MetaCard/Revolution. We still have to restart the process on weekly basis to clear the leaks. The process open 3 to 5 thousands files a day, size from a few kilobytes to 200 Mb.
I do hope RunRev forthcoming apache mod would be similar to PHP mod, which offer "long-running" alike environment for xTalk script, yet provider true multi-thread.
Give me a shout when you need someone to test it out, even it is on early alpha stage. We have over 400 thousands lines of code written in xTalk running as CGI - it is very good in exploiting the engine bugs ;)
--
1. MetaCard/Revolution built-in TCP/IP server socket used to listen to incoming traffic. The socket command in revolution is very robust to use as a "client", not really reliable as server. We have attempted this a few times in the pass, unfortunately we have to restart the process couple of time a day, even with pretty light traffic (few thousand hits). Although this could be partly due to our bad programming, turning it into executable script behind xinetd seems to solve the problem - but that basically back to CGI implementation similar to apache.
2. The process isn't really multi-threaded. Although the event based socket command provide some kind of schedule and distributed execution environment, a badly coded handle can hog the entire process down, and queue up the subsequent hits.
3. Increase the complexity on coding. We have to "release" the process cycle in a CPU intensive task by doing "wait x milliseconds with messages" in order to ensure other handle get the turn on execution. Unfortunately, this is not always possible as the task can be unpredictable in certain conditions, like waiting for a complex database query to come back etc.
4. Memory leaks. I don't know about others, it seems to me there is definitely some memory leaks somewhere in MetaCard/Revolution. We still have to restart the process on weekly basis to clear the leaks. The process open 3 to 5 thousands files a day, size from a few kilobytes to 200 Mb.
I do hope RunRev forthcoming apache mod would be similar to PHP mod, which offer "long-running" alike environment for xTalk script, yet provider true multi-thread.
Give me a shout when you need someone to test it out, even it is on early alpha stage. We have over 400 thousands lines of code written in xTalk running as CGI - it is very good in exploiting the engine bugs ;)
--
>>
1 ...we have to restart the process couple of time a day, even with pretty light traffic (few thousand hits).
<<
That would appear to run contrary to Pierre's experience. I would suggest you write to him and ask for more information. As I said, he was programming web applications for the French government. I can't find any of the posts right now, but he was referring to very high workloads and was saying that his Rev based solution compared favourably (i.e. out-performed) a Java based solution.
>>
2. The process isn't really multi-threaded. Although the event based socket command provide some kind of schedule and distributed execution environment, a badly coded handle can hog the entire process down, and queue up the subsequent hits.
<<
I don't see how any apache module for Rev will make any difference to this. It is not going to make Rev a thread-based rather than an event-based language (and there's good arguments for NOT being thread-based). The only benefit that will come will be from the engine not being restarted between calls (a la Pierre's model) and from running multiple simultaneous engine processes. It's some years since I looked at Pierre's model, but I expect there are ways you could scale by running multiple instances now.
>>
3. Increase the complexity on coding. We have to "release" the process cycle in a CPU intensive task by doing "wait x milliseconds with messages" in order to ensure other handle get the turn on execution. Unfortunately, this is not always possible as the task can be unpredictable in certain conditions, like waiting for a complex database query to come back etc.
<<
Again, I'm not sure that have Rev apache modules will make any difference here.
>>
4. Memory leaks. I don't know about others, it seems to me there is definitely some memory leaks somewhere in MetaCard/Revolution. We still have to restart the process on weekly basis to clear the leaks. The process open 3 to 5 thousands files a day, size from a few kilobytes to 200 Mb.
<<
I suffered so much unpredictable crashing with Rev 2.9 (on Vista) and 3.0 (Vista and Linux), I gave up using the development environment on any platform except OS X. Once again, I suggest you contact Pierre. I seem to remember he was streaming Quicktime movies as part of his solution.
I personally wouldn't dream of creating a web application where Revolution was acting as a server. As far as I can see this is an area where Runrev have failed to put significant resources. So often I have seen what a huge struggle experienced users have had just in getting the engine to run as a CGI. However, as you are already a long way down that path I think Pierre is the person who has probably got more experience in this area than anyone else. If I remember rightly, he's been doing this for over 7 years.
1 ...we have to restart the process couple of time a day, even with pretty light traffic (few thousand hits).
<<
That would appear to run contrary to Pierre's experience. I would suggest you write to him and ask for more information. As I said, he was programming web applications for the French government. I can't find any of the posts right now, but he was referring to very high workloads and was saying that his Rev based solution compared favourably (i.e. out-performed) a Java based solution.
>>
2. The process isn't really multi-threaded. Although the event based socket command provide some kind of schedule and distributed execution environment, a badly coded handle can hog the entire process down, and queue up the subsequent hits.
<<
I don't see how any apache module for Rev will make any difference to this. It is not going to make Rev a thread-based rather than an event-based language (and there's good arguments for NOT being thread-based). The only benefit that will come will be from the engine not being restarted between calls (a la Pierre's model) and from running multiple simultaneous engine processes. It's some years since I looked at Pierre's model, but I expect there are ways you could scale by running multiple instances now.
>>
3. Increase the complexity on coding. We have to "release" the process cycle in a CPU intensive task by doing "wait x milliseconds with messages" in order to ensure other handle get the turn on execution. Unfortunately, this is not always possible as the task can be unpredictable in certain conditions, like waiting for a complex database query to come back etc.
<<
Again, I'm not sure that have Rev apache modules will make any difference here.
>>
4. Memory leaks. I don't know about others, it seems to me there is definitely some memory leaks somewhere in MetaCard/Revolution. We still have to restart the process on weekly basis to clear the leaks. The process open 3 to 5 thousands files a day, size from a few kilobytes to 200 Mb.
<<
I suffered so much unpredictable crashing with Rev 2.9 (on Vista) and 3.0 (Vista and Linux), I gave up using the development environment on any platform except OS X. Once again, I suggest you contact Pierre. I seem to remember he was streaming Quicktime movies as part of his solution.
I personally wouldn't dream of creating a web application where Revolution was acting as a server. As far as I can see this is an area where Runrev have failed to put significant resources. So often I have seen what a huge struggle experienced users have had just in getting the engine to run as a CGI. However, as you are already a long way down that path I think Pierre is the person who has probably got more experience in this area than anyone else. If I remember rightly, he's been doing this for over 7 years.
I have just skimmed thru Pierre's codes sample, it uses php to interact with single revolution process, which has the benefit of fast respond time without the overhead of process startup.
However, such framework is only good if you don't expect slow disk I/O (no need for disk read/write) or long database queries.
Let me give an example:
At the existing CGI framework, the following code can be executed simultaneously, and all the browsers that hit the same code will get the result in 3 seconds:
on myCGI
wait 3 seconds
write "Content-type: text/plain"& crlf & crlf &"Hello world!" to stdout
end myCGI
In a long-running Revolution process, only the first browser hit the code get 3 seconds respond. If there is 5 users accessing the same code at the same time, the last person will have to wait for 15 seconds in order to get the "Hello world!" respond.
For this reason, we are still sticking with the CGI framework and pay the price of having to restart revolution instance at each click on the browser *.
Since the cost of the multi-core CPU and RAM coming down a lot, we get to survive and justify our projects by running revolution mainly at the back - still.
At this moment, we are putting 8 Gb RAM, Quad core Xeon machine just to serve 300 to 500 concurrently web users. We are losing some competitive advantage in term of performance/hardware.
I must say this is the same situation for Perl, PHP and Java if they are running as CGI. Fortunately, they all have some kind of apache mod and even their own dedicate http server (tomcat for java) for scaling up.
I've been coding in xTalk since the HyperCard days, and even run a few production servers with HyperCard as CGI with WebSTAR (a popular http server for MacOS 9). This is why I am still tricking revolution today to do more stunt at the server ;)
--
* it wasn't that bad, Linux cache things up pretty nicely so there isn't any I/O involved once the first instance completed.
However, such framework is only good if you don't expect slow disk I/O (no need for disk read/write) or long database queries.
Let me give an example:
At the existing CGI framework, the following code can be executed simultaneously, and all the browsers that hit the same code will get the result in 3 seconds:
on myCGI
wait 3 seconds
write "Content-type: text/plain"& crlf & crlf &"Hello world!" to stdout
end myCGI
In a long-running Revolution process, only the first browser hit the code get 3 seconds respond. If there is 5 users accessing the same code at the same time, the last person will have to wait for 15 seconds in order to get the "Hello world!" respond.
For this reason, we are still sticking with the CGI framework and pay the price of having to restart revolution instance at each click on the browser *.
Since the cost of the multi-core CPU and RAM coming down a lot, we get to survive and justify our projects by running revolution mainly at the back - still.
At this moment, we are putting 8 Gb RAM, Quad core Xeon machine just to serve 300 to 500 concurrently web users. We are losing some competitive advantage in term of performance/hardware.
I must say this is the same situation for Perl, PHP and Java if they are running as CGI. Fortunately, they all have some kind of apache mod and even their own dedicate http server (tomcat for java) for scaling up.
I've been coding in xTalk since the HyperCard days, and even run a few production servers with HyperCard as CGI with WebSTAR (a popular http server for MacOS 9). This is why I am still tricking revolution today to do more stunt at the server ;)
--
* it wasn't that bad, Linux cache things up pretty nicely so there isn't any I/O involved once the first instance completed.
Here is the link for the related article on PHP alike Rev engine:
http://www.runrev.com/newsletter/may/is ... etter1.php
http://www.runrev.com/newsletter/may/is ... etter1.php
RunRev launched on-rev!
RunRev has just made the server-side xTalk available via www.on-rev.com.
But it seems they are selling it as software-as-service, instead a commercial application, like RunRev Studio.
It is still at the alpha stage, so can't say much about the company intension. But anyone has more information about on-rev back-end?
It is indeed getting really interesting...
But it seems they are selling it as software-as-service, instead a commercial application, like RunRev Studio.
It is still at the alpha stage, so can't say much about the company intension. But anyone has more information about on-rev back-end?
It is indeed getting really interesting...
I jumped on it and must say it is just wonderful. Coding rev just like we do PHp, but guess what? As soon as we considder the beast stable enough in house we will no longer need to outsource any PHP work. It is an alpha, but I have seen shipping products much worse. I am a really happy camper with on-rev.
Cheers,
Malte
Cheers,
Malte
In one of their newsletter titled "Are You On-Rev yet? Founders deal ends Friday" (via email), I've found this:keyless wrote:Yeah, I'd like like to know if Rev intends to release the server side engine so those who run their own webservers could use it.
"Once the irev technology is ready for full release we will make available an engine for installation on any server."
It is confirmed that irev engine will be available for everyone!
--
The new irev engine vs CGI rev engine
Different between RunRev CGI and irev engine:
- There is some kind of persistent irev engine running on the server (ireviam), but the engine will be still do the conventional loading/tear-off on each query/instant hit to the server.
- The irev runtime works almost identical to CGI environment, you start new on every call. You have to re-load your data every time.
- Good runtime debugger with on-rev app, offer line-by-line code step thru - this alone, worth for the money you pay
- Nice development platform on-rev app, offer easy code upload and write them online.
- PHP/ASP alike parsing on .irev files, with special opening tag <?rev and closing tag ?>. Not sure if it supports mix tag on PHP or ASP -- or is this being done on other embedded language before?
- Browser form submission and URL parameters are available at $_GET and %_POST as array automatically, but for file upload (or enctype="multipart/form-data"), you have to unpack the data from stdin (fortunately someone already did that, with sample codes).
- $_SERVER array gives you all the host environment information, like client IP, browser agent etc.
- Database connection is first class, available for MySQL, PostgreSQL and SQLite.
- Use "put var" to write content back to the browser, similar to CGI, but the first put command will immediately write your content to the "body" of the return result, not the "header". Use "put header var" to write to header before a normal put function.
- No stacks supported, meaning you cannot encrypt your code library (work in progress).
- Use a new include command to cascade "library" or long code from other files.
- new (enhanced) commands:
put content var
put header var
- No persistent global variable.
- There is some kind of persistent irev engine running on the server (ireviam), but the engine will be still do the conventional loading/tear-off on each query/instant hit to the server.
- The irev runtime works almost identical to CGI environment, you start new on every call. You have to re-load your data every time.
- Good runtime debugger with on-rev app, offer line-by-line code step thru - this alone, worth for the money you pay
- Nice development platform on-rev app, offer easy code upload and write them online.
- PHP/ASP alike parsing on .irev files, with special opening tag <?rev and closing tag ?>. Not sure if it supports mix tag on PHP or ASP
-- or is this being done on other embedded language before?- Browser form submission and URL parameters are available at $_GET and %_POST as array automatically, but for file upload (or enctype="multipart/form-data"), you have to unpack the data from stdin (fortunately someone already did that, with sample codes).
- $_SERVER array gives you all the host environment information, like client IP, browser agent etc.
- Database connection is first class, available for MySQL, PostgreSQL and SQLite.
- Use "put var" to write content back to the browser, similar to CGI, but the first put command will immediately write your content to the "body" of the return result, not the "header". Use "put header var" to write to header before a normal put function.
- No stacks supported, meaning you cannot encrypt your code library (work in progress).
- Use a new include command to cascade "library" or long code from other files.
- new (enhanced) commands:
put content var
put header var
- No persistent global variable.
-
imed-edition
- Posts: 12
- Joined: Fri Apr 21, 2006 1:53 pm
Is it officially confirmed that the irev technology will be available for installation on any server?beix wrote:In one of their newsletter titled "Are You On-Rev yet? Founders deal ends Friday" (via email), I've found this:
"Once the irev technology is ready for full release we will make available an engine for installation on any server."
It is confirmed that irev engine will be available for everyone!--
For our company this is a blocking issue since our market is about patient's data and we cannot consider this technology without keeping full control on the data and application servers. External hosting is not an option for our customers.
Any official link would be appreciated on such a topic.
Thanks.
-
Janschenkel
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
The RunRev team has already stated it will eventually make the cgi-engine available in a separate revServer package. The strategic advantage of the On-Rev offering is the tight integration with the client app and the fact that everything is already setup on their server and they take care of the maintenance.
Jan Schenkel.
Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com