Rodeo, revServer etc.

[Chipp Walters]

Sarah,

It would be so sad to see you go. You have been a well respected and
most helpful community member for so long. And, I'm especially sorry
to see you go in such a sad way.

I understand that you and Jerry have ventured into some new uncharted
waters and that architecting server apps while starting a brand new
company can be a daunting task for anyone. Heck, Chris and I have
helped Jerry create architectures for multiple-tier server
applications for a number of his clients in the past, and it's never
an easy task. And, truth be known, I don't know any more than either
of you when it comes to the hard core details of what's going on at
those servers AND that's why I have people like Chris and Andre and
Pierre and this list who help steer me clear of some of the potholes
you guys evidently stepped into on this project.

Still, my understanding is that Jerry is in weekly contact with Kevin
via RevSelect, so I suspect communication isn't a HUGE problem, and
you all have done a marvelous job at promoting your application here
on the use-list, so i'll chalk up the last minute parting cheap shots
toward Rev to an overall frustration at this whole situation.

I get it you are upset. The fact you can't reproduce your problems may
be due to many different issues, as both Andre and Kevin point out.
Certainly trying to debug these issues in a shared hosting environment
didn't simplify things. But how were you to know? I think Rev should
have probably taken a more active role in bug and recipe hunting,
especially since there are so many factors and given the limited
expertise. But there are ways to test these things and to produce a
recipe, and that is all I was saying. Having this discussion here
after publicly posting on your blog to your users, most of whom follow
this list should be no surprise. We all want to know how real the
problem is and why it happens.

You have been and are an extremely valuable resource to this community
and will be sorely missed if you go. I've enjoyed working with you on
projects in the past and have always found you to be the highest in
terms of integrity and professionalism. I would encourage you to
reconsider leaving.

On Wednesday, August 4, 2010, Sarah Reichelt <sarah.reichelt at gmail.com> wrote:
> 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>