What's The Verdict, Web or Not?

[Brian Yennie]

> 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.)

I meant company resources - Supercard made a lot of us wary of these 
kinds of projects for better or worse, as it ate up several companies 
along the way. Windows port, browser plugin, they both quite literally 
sunk small companies. BTW - Supercard was not an Apple product - only 
Hypercard was. Supercard was owned by a string of small companies much 
like RunRev (in size, I must say RunRev has had more success than any 
of them IMO).

> 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.

Fair enough. I would argue that Director was still not a RAD tool and 
more of a media-creation application... but, it's almost hopeless to 
argue that one and probably should be tabled =).

> 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.

Fair enough. FWIW, there is the ability to run Rev stacks in safe mode 
already and block file system access. The system property isn't coming 
to mind now, but it's there.

> 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.

Well I'll be honest - I'm much more in the camp of not wanting RunRev 
to use it's resources for this than I am of the mind that I wouldn't 
like to see it.

> 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!" :)

Mostly agree. I don't necessarily think it's on the critical survival 
path for Rev, HOWEVER, I would surely get a kick out of seeing it 
happen.

Here's on last thought, before I should probably rest my thoughts on 
the issue: Metacard Corp. used to license "embedded" Metacard to 
developers with very special needs who needed to link Metacard 
(Revolution) directly into their own custom applications as a C-code 
library. If a 3rd party group could convince RunRev to license the code 
out, it could be conceivably the best of both worlds: a browser plugin 
developed without RunRev as a company taking such a big risk with it's 
resources. I would be more than happy myself to even pitch in a little.

- Brian