On Dec 10, 2008, at 9:11 PM, John C. Welch wrote: Honestly? Were Apple to be more...arsehelms about osax intruding on namespaces, a lot of this would go away.
If there were no compatibility requirements for scripting additions, I'd favor simply changing them all to always run in the sender's process—that probably should have been the original design, by default at least. But for compatibility reasons we can't make a nice, simple change like that. OS wins over OS-supplied OSAX win over Applications win over third party OSAX. Always. Don’t be nice about it. Don’t even let conflicting OSAXen load.
Actually, OSAX loading is intentionally inverted from that. A user-supplied OSAX can override a system-supplied OSAX. If we did it the other way around, that would mean no user could override an OSAX without modifying /System, affecting all users on that machine. More to the point, if the user already has an OSAX they're using and then we added new commands in the future that happen to have the same terms or codes, we'd break that user's scripts—even though they weren't attempting to override system-supplied additions before. When an OSAX loads, AppleScript should eval them, and if there’s a conflict that the OSAX loses, unload it, and kick out a dialog to the user. Make it easier when building OSAXen to at least check against OS and existing application namespaces. (you can’t test for EVERYTHING, but you can at least make it easier to check against standard OS and “standard” application namespaces.)
This is one reason why additions developers should update to the new (introduced in Mac OS X 10.5 Leopard) Info.plist-based OSAX format, and they should avoid supplying wildcard handlers. This new format enables OSA (and AppleScript) to examine them to see what commands they handle, and to have more control over when, if and how their code is loaded and executed.
In the longer term, what we need is fine-grained namespace control, generally, not just a change to the override order of OSAX loading.
-- Chris Page
The other, other AppleScript Chris
|