What's The Verdict, Web or Not?

Bill Marriott wjm at wjm.org
Mon Jul 3 01:05:13 EDT 2006


Brian Yennie wrote,

> I see no problem with anyone else salivating over a Rev plug-in. Heck, I'd 
> probably find some use for it if there was one.

:)

> It's not spurious. There's history here. Roadster (Supercard web plug-in) 
> did an excellent job of sucking resources and falling on its face with a 
> company similarly equipped to RunRev (i.e., small). And Roadster was a 
> significantly smaller technical feat, because it only ran on one platform.

Resources is one thing; bugs are another. (And did you mean, system 
resources, or company resources?) Sophisticated Flash solutions can take up 
several megabytes of RAM. More than a similar Rev standalone, in some cases. 
As for Roadster, I am sure that Apple didn't particularly care about making 
it cross-platform; they're funny/weird that way. (Apple *still* offers a 
non-xplat plug-in architecture.)

By a plug-in "comparable [to Rev]" I mean Director of course. Director's 
lingo is/was even a variant of HyperTalk, before it transmogrified into a 
multi-headed ECMAscript beast.

> Revolution is hugely intertwined with OS-specific calls, file system 
> access, multiple windows and a ton of other stuff that just doesn't fit in 
> a browser window.

In one of my earlier posts, I did comment that the browser "sandbox" would 
be the hardest aspect of a Rev plugin. Presumably one wouldn't be able to 
access the local system at all. And you wouldn't be able to spawn new 
windows, either. Not all technical issues are "spurious" but some of the 
ones bandied about certainly are.

By the way... Clearly this is about using Rev to write "stacks" that target 
the browser... not to expect to run any Rev stack without modification 
"within" a browser window.

> I'm not saying it's impossible. Of course it's not. But raising technical 
> objections is quite sound here. I've written externals for Revolution, 
> compiled and modified Mozilla from the source, am familiar with the 
> browser plugin API -- and I can barely imagine trying to fit Revolution in 
> there. It's a much taller task than any plugin I know of. There ARE 
> technical reasons why you don't see entire RAD environments running inside 
> browsers. And no, Flash is not a RAD tool.

And since Rev itself can't access the document object model, presumably a 
plugin woudn't be able to either, severely limiting its functionality. Yes, 
there would be some issues trying to get the existing Rev shoe-horned into a 
browser plugin. However, building a plugin that can present rev stacks is 
another question :)

> Anyway, perhaps we can agree - there are more than spurious technical 
> hurdles, but some of us think they would be worth it (even though I do 
> not).

Yes...  it's a big job. My point is NOT that "Oh those Rev folks are so 
mean, they could just wave a hand and give us something we want, 
effortlessly." There are issues, sure. Solvable ones. I reject the claim 
that Rev is not "appropriate" for web delivery, or inherently incompatible 
with the concept, as spurious.

I think many (perhaps even most) regulars here on the Rev list have accepted 
the niche Revolution has found and hopes it continues to be maintained and 
thrive in that niche. We feel lucky that Rev, such as it is, even exists... 
let alone that it works as well as it does to create "real applications" on 
the "big three" OS platforms. But you know, there is no "President Bush" who 
is going to declare our coral reef a wildlife sanctuary. Rev is going to 
have to adapt long term to survive, in my opinion. I think that means 
eventually running on the Web -- the latest and most important "platform" 
out there. As Stephen Hawking said, "Leave Earth or die!" :) 






More information about the use-livecode mailing list