Hi All, Kevin has given his point of view over Rodeo and revServer, and then forbidden us to comment, leaving us without the right of reply. Of course it is his list and he is quite at liberty to ban whoever he chooses, and if the matter had ended there, I would have let it slide. Unfortunately, discussion has continued and has expanded to a direct and personal attack on Jerry, which by association is an attack on me. So I have decided, reluctantly, to ignore Kevin's instructions and post my thoughts on the issue. I realise this will lead to my removal from the list, but that is a consequence that I am prepared to accept.
Before I go, I would like to say goodbye and thank you to everyone here. I have thoroughly enjoyed most of the interactions on this list and there are many of you here that I regard as real friends, despite never having met you in person. There are too many of you to mention individually, but you know who you are. Now on to revServer: as soon as I heard about revServer, I was incredibly excited. I bought it as soon as it was released and I converted my entire web site to run using irev scripts. RunRev even used my examples page in their promotional mail outs, so I think everyone can see that I am a great supporter. The advertising material announced "Blistering Performance" which unfortunately never eventuated. Even on my modest web pages, often a page would only half-load. I frequently had to tell people just to give it a minute and the data came through in the end. However for my own web site, this was not really a problem. I think nobody will dispute that the On-Rev client is a big disappointment. It's primary feature was the debugging, but as soon as I added a new domain to my site, this stopped working for me. Heather was unable to find out why and nearly a year later, I am still waiting for the engineer to get back to me as promised. However the On-Rev client is a completely separate application and using revServer does not require it. I switched to using other apps to do my editing and file transfers and I debug using log files. CGIs are a different matter. I assume that many people on this list have done what I have done and written CGIs that are called from Rev stacks. These caused problems as the default socket timeout in Revolution is 10 seconds. Many times, this is not enough time to get an answer back from the On-Rev servers, even for a very simple CGI. So for anyone in this situation, it is essential to increase the socketTimeoutInterval before calling an On-Rev CGI. Before I got into more intensive use of the On-Rev servers, other people ran into the server's timeout limits. These were confirmed by Oliver from RunRev on the RunRev forum <http://forums.runrev.com/phpBB2/viewtopic.php?f=8&t=4791>. Now on to Rodeo: our original planning for Rodeo was based entirely on revServer technology. They seemed like a perfect match. Jerry & Kevin had discussed it and Kevin had agreed that there was nothing in the Rodeo plans that conflicted with anything he and RunRev were planning to do. So we proceeded with his blessing. The first thing we found was that there was an extreme variation in the time taken to complete any given CGI request. Kevin has just posted the results of Mark's tests and they confirm what we suspected and asked Kevin about - that the server effectively needs a wake-up call before it gets going. Other test results posted on the lists have shown similar effects. However it does not seem to be always a wake-up issue. I have one utility that loops through a series of folders doing the same action for each folder. I started off by making this a single CGI and the CGI on the server assembled the folder list and performed all the tasks. Once I had more than a few folders, this stopped working, so I re-wrote the CGI so that I assembled the folder list and then sent a separate CGI call to the server to deal with each of the folders. Watching the progress of this is very interesting: The first call is nearly always slow, then I might get 4 or 5 inside a second, then it will slow down again for the next couple of calls, then speed up again. Chipp has repeatedly called on us to provide recipes for our problems, but this is not really possible. The first problem is the server timeout, which has been stated by RunRev so does not require any recipe. The second problem is the varying response times and as the same CGI will produce widely varying response times, I am unable to provide more of a recipe than that, as already reported to Kevin and confirmed by Mark's tests. Andre's tests have now demonstrated that the timeout issue is in the On-Rev server and not in revServer itself. This is excellent news, and I would still recommend revServer to anyone. But we were unable to get an answer from anyone at RunRev on this subject and did not feel justified spending $300 on an experiment, so for Rodeo, we have chosen a different route. But revServer is a wonderful prototyping tool, even if it is not the final production tool. As part of the Rodeo feature list, we announced a new way people would deploy their Rodeo web apps. This involved calling a CGI that converted their existing development app into a non-editable and public version. So as to be honest with our paying customers, Jerry mentioned that due to the acknowledged timeout issue with the On-Rev server, this might fail with a large app. This comment was taken - by a third-party - to the Rev list where it caused the current flame war. Part of the problem here is that as RunRev customers, we get very little communication from RunRev. We get announcements of great products that are not followed through: revServer is apparently still in alpha after more than a year, Rev 4.5.0-dp-3 was released in March and despite the basic flaw in libURL, has not been updated. I made it work using Trevor's fix (thanks Trevor), which would have taken the RunRev team about 30 seconds to apply, but they have not done so. I realise they were shaken by the revMobile fiasco - we all were. Remember that many of us paid a large sum of money for a product that will no longer do what we bought it for and a conference that has been cancelled. At least RunRev ended up with the money! But Apple can only be blamed for so long. At some stage Kevin and his group have to take responsibility. It is good to read Kevin's plans for better bug reporting, better communication, more products etc., but those of us who have been here for a while have heard all this before. Finally, a comment on this list itself. I know this is a long post, but it is my last one, so I have to get everything in. Some people on this list have a habit of shooting the messenger. Anyone who dares to suggest that there is anything less that perfect about RunRev is shouted down, and most of them just leave instead of being converted. The most noticeable exception to this was Bill Marriott. Bill was an extremely out-spoken member of the list who got very angry at the way bugs were being ignored. He got flamed on the list, but to Kevin's enormous credit, he hired Bill and put his anger and enthusiasm to work for RunRev. This worked extremely well and I am sure we all miss Bill. In fact I wonder how this situation would have been handled had Bill still been around. Since I anticipate my imminent removal from this list, anyone who would like to respond is invited to email me directly: [email protected] So long, and thanks for all the fish! Sarah _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
