Re: [Gnash-dev] proprietary player compatibility macros

[Eric Hughes]

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