Where Rev could be going...

[Mark Wieder]

Bernard-

Wednesday, November 22, 2006, 3:39:10 AM, you wrote:

> As I've said, it's not currently a high priority for me, but it seems
> to be quite important to other users.  If we knew what the  
> limitations were, then maybe we'd stop pestering Runrev for it :-)

It's doubtful. Yes, this seems to pop up on the list every six months
or so. Here are a few related reasons why this won't work:

Without fastcgi every call to a rev cgi invokes a new instance of the
rev engine. With fastcgi the engine is always running on the server.
In the first case you have no persistence of variables - it's the
nature of http not to have session transactions, but only single
calls. In the second case you have persistence, but no way to separate
user namespaces without special-case coding. You run into a situation
where scripts are either reentrant and ephemeral or persistent and
non-reentrant. More: blocking calls are deadly in either situation -
threading would help with that one, but possibly cause more problems
than it would solve. Also, only a subset of non-GUI rev actions are
translatable to the web - "go previous card", for example, or "answer
file" not only won't work, but the engine will stop executing scripts
on coming across that directive. Http as a protocol does not guarantee
the delivery of packets. Thus network traffic or whatnot could
interfere with the execution of script commands.

And anything short of full Transcript functionality in a web
experience would be a tech support nightmare, trying to explain why
certain scripts work and others don't. Runrev as a company would not
only be in the same situation as now with users complaining about
things that don't work on the web, but would create problems for their
tech support because they have attempted to implement only a subset of
scripting functionality. CGI scripts would have to be hand-crafted the
same as they do now.

> I'm sure all of us would prefer that Rev's engineering resources are
> not consumed by the production of a browser plug-in.

Indeed. I'm sure BZ #624 would be an easier thing to fix.

-- 
-Mark Wieder
 mwieder at ahsoftware.net