These are all good points. I do like the idea of a special extension for application-based .mf files.
Note that security with a web browser plugin is a going to be a major issue, and one not yet solved. The problem is that Python itself is real hard to secure, by its nature–simply prohibiting arbitrary C++ code from running doesn’t help at all to secure the plugin, because arbitrary Python code is just as bad. People have made attempts to secure Python from time to time, and they all either (a) don’t actually work, or (b) cripple the Python runtime so much that it can’t do anything.
I might be a little harsh in my estimate for (b). In our case, we don’t actually need to protect Python code from compromising other running Python code, unlike the Zope project. All we really need to do is prevent arbitrary disk writes, which might be doable by simply recompiling Python with a crippled file object that cannot write anything. And then we can require users to go through the Panda mechanism (e.g. direct.stdpy.file) in order to write to disk, and that code we can lock down.
I’m now thinking the runtime itself should manage multiple versions. Kind of like the way DirectX works, with all of its backward compatibilty internally built-in. The runtime would load up the mf file and check what version it requires, and if it requires an older version of the current runtime, then it would automatically switch to that older version before continuing. This would all have to be packaged up within the same application/plugin/whatever, so it would have to be a pretty smart system, ideally even capable of automatically downloading and installing the appropriate versions when needed.
David