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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
