Rodeo, revServer etc.

[Sarah Reichelt]

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:
sarah.reichelt at gmail.com

So long, and thanks for all the fish!
Sarah