Richard Gaskin said:
>>
One of the hardest things in making a browser plugin is dealing with the
limitations of the environment: no file I/O, no Apple events, no
Registry access, no windows, no window styles, etc. In a comprehensive
superset of HyperTalk like SuperTalk and Transcript, doing that many
IFDEFs across the code base is a lot of work (and characterizing the
work as simply IFDEFing is of course a generously lighthearted metaphor
for the true nature of the rework).
<<
Hi Richard,
Thanks for those comments. I think they give us something to think
about.
I want to continue this discussion a little further to see if my
understanding is correct: 1) any Rev app that would run in a browser
plug-in could only offer a sub-set of Rev functionality 2) there
would need to be a lot of conditional coding in the engine to check
which environment the code was running within, in order for the plug-
in to know what it could and could not attempt to do.
The former set of limitations is not that different from Rev running
in secureMode. The Dictionary says:
>>
If the secureMode property is set to true, the application cannot use
the get, put, open file, read from file, or write to file commands to
gain access to local files. The application cannot run programs with
the shell function, the open process command, or the launch command.
On Windows systems, it cannot use the deleteRegistry, queryRegistry,
or setRegistry functions to access the Windows system registry.
<<
So, we already have that concept of a player application with limited
functionality. That looks to me like the engine already contains
conditional processing for secureMode. I'm wondering if this browser
plug-in couldn't be done as an extension of secureMode. However, if
we could make explicit what all the different limitations would be,
then maybe the advocates of a plug-in will conclude that it is not
something they would find particularly useful (e.g. if it meant they
had to code a different version of their app to work with a browser
plug-in.) I'm still ambivalent about it myself.
The additional limitations you mention are things like the absence of
windowing. It would be good if those more experienced developers
(either pro or con the browser plug-in) could give some thought to
what the other limitations might be. One thing I can imagine
(although I could be way off base here), is that since Rev relies on
being able to grab more and more memory as the data/resources in a
stack increase, maybe that too would be a limitation (browsers might
well try to limit how much memory a plug-in is trying to allocate in
the name of the browser).
Bernard
_______________________________________________
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
