On-Rev: from the outside looking in

[Martin Baxter]

Brian Yennie wrote:
> Had a thought. Dangerous, I know. To me the power of On-Rev is two things:
> 
> 1) Opening up server side scripting to Rev users that wouldn't otherwise
> go there
> 
> and
> 
> 2) Bring xTalk to server-side developers in general
> 
> These are both worthy tasks, but I think it's worth differentiating
> between the two. Depending on which perspective you are coming from, any
> example is going to be taken differently. To put it simply, a PHP
> developer won't be impressed by something they could do with roughly the
> same effort in PHP. However, a Rev developer might be thrilled because
> now they don't have to learn PHP!
> 
> What I'm really interested in is #2, because I'm experienced with PHP /
> Perl / Java / etc on the server side. So why would I consider onRev?
> 
> 1) Integrated debugger
> 
> and
> 
> 2) xTalk syntax
> 
> What I think would really shine light on onRev is an example that shows
> off file handling / URL syntax and chunk expressions. In other words, it
> needs to show off the strength of the language, not just the fact that
> it runs server-side. So what kind of web app would lend itself to URL
> syntax and chunk expressions, making it way more efficient in xTalk than
> any other language?
> 
> OK, that was my thought. I didn't say I had the answer.
> 
> - Brian

Brian,

I write PHP a lot, I'm obliged to wrestle with javascript, I've done a
little Perl, have recently decided to learn Python, plus I am moderately
familiar with hosting customer websites of many kinds. And I've asked
myself the same sort of questions you are asking about onrev. As you
suggest, the appeal, if any, will probably depend on personal
circumstances, as in the general case the appeal appears weak, if this
is considered only as a server-side scripting technology a la php etc.

As a hosting package, the founder on-rev package isn't especially
exciting to someone already established as a web-hosting reseller (e.g.
me). But at the same time it is quite a deep pond for a raw beginner. It
isn't very suitable IMO for hosting customer sites, it's more of a
specialised personal hosting account. What it is presumably intended for
is as a platform for web applications. As far as I'm concerned, its
appeal is its potential as a back-end service to other sites hosted
elsewhere. Anyway, this initial package need not be part of the wider
argument.

xtalk text chunk handling is what I miss most in php, javascript etc,
but apart from that, I agree with what you suggest: language features
alone provide no strong argument for using rev over other options. Plus
PHP, for example, is essentially free and massively supported while Rev
costs money and is proprietary. For a complete newcomer to rev, adopting
it as a server-side scripting language in the face of other options is
not very compelling at this point.

I'm not a newcomer to it though so have a different outlook. I already
have a sprawling mess of an application written with RR that generates
entire websites, plus a mess of 10-minute-quickie-utilities lying around
waiting to be re-used.

Personally I can see benefit in being able to integrate that setup with
server-based services written, or partly-written, in the same scripting
language - I can re-use existing concepts, data structures and code
fragments to provide satellite services that dovetail with the way I
work back at home. As an adjunct to existing desktop applications made
with sibling technology, it has merit.

The immediate challenge to me is to integrate it with my existing
working procedures*. I dutifully downloaded the onrev application, ran
it a couple of times, scratched my head wondering what it was meant to
be for, and quickly went fumbling back to the comfort zone of my trusty
text editor, where I already spend much of the time. Perhaps its value
will become clear when my experiments get a bit more complicated.

Since I can't install onrev as an apache module in my dev server at
home, onrev is sort of out in the cold as far as my daily work is
concerned - code, save, point browser at localhost, test. Can't yet do
that with onrev though. I prefer to code in my private sandbox. Existing
systems let me do that. I see this as a barrier to wide acceptance.

On the philosophical level, I may be to marketing what Kryptonite is to
Superman but I suppose that runrev see on-rev as a component that
enhances the existing product - revolution is very desktop-oriented, cgi
aside, and cgi isn't everyone's cup of tea or always appropriate. On-rev
is like Revolution growing tentacles into serverspace. I doubt that
on-rev will be proposed as a standalone technology, marketable on its
own. Look at it another way, how many people use PHP to make desktop
applications?

I would think this founder launch of on-rev is partly to tune and debug
and get feedback and perhaps partly in hope that some cool examples will
emerge.

Put Merge("My 2 [[local_currency()]]s")

Martin Baxter

*I initially wrote 'workflow' but then remembered the reality of my
working day, for which 'flow' is not the right word. ;-)

-- 
I am Not a Number, I am a free NaN