At 04:14 PM 7/24/2007, strk wrote:
Implementing multiple emulation modes would also be challenging (emulate
this version on
this system, that version on that system).
Do we really want to go there ?
My opinion is "yes".
The best way I've found to think about this kind of problem is to view a
language interpreter as an "execution service". That is, it's a facility
available to execute scripts. As a facility, it's a servant to whatever it
is that requires its capabilities. The user may be expecting some
particular kind of service; the most common variant is by version number.
Now suppose, contrary to fact but not to possibility, that there were a
service identifier (think super-duper-version-number) that completely
specified all the variation is behaviors of the class of services in
question. Ideally, a user would say "I want behavior-set SX21". The
interpreter would provide such a service in whatever way it could,
including, perhaps, dispatching execution to a version-specific
binary. (There's a bit of this going on with version-specific loading of
dynamic libraries.)
The question resolves down to two main issues:
1. Given that no behavior identifier exists as a standard, what is a
reasonable substitute?
2. By what mechanism should variations in behavior that the system as a
whole support be presented?
I have posed the issue of variation in as an inversion to the ordinary
relationship of code to its interpreter. The ordinary way is that the
interpreter sits high and mighty and requires programs to conform to
it. It is then the job of the programmer to write a piece of software that
can serve multiple masters. The inverse way is for the program (or user)
to ask the interpreter to behave in an appropriate way.
I believe Gnash should serve its programmer-users, rather than requiring
them to serve it.
Eric
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
