I've heard that when a Mac app implements their version of the Standard AppleEvent suite, the developer can copy "CocoaStandard.sdef" and trim out whatever they don't need. What are the constraints on this trimming?
Well, strictly speaking, there aren't any. The point of the sdef file is to map a human-readable syntax onto the AppleEvents your app chooses to implement. There isn't really much point in limiting your app’s ability to modify the content of the definition file, given that your app has full control of what it actually does regardless of what the sdef file says. For example, we can't really "require" even a basic event like "quit", given that your app doesn't actually have "do" anything when it receives that event.
I guess that we could remove commands wholesale, but can we remove sub-parts of a command? Can we change an enumeration? A record type?
Have you taken a look at TN2106: "Scripting Interface Guidelines"? That document was basically written to provide the same kind of guidance for script interface design as the HIG does for interface design.
That document covers a lot of territory, but the issue here isn't really what's "possible", it's how usable and understandable your script support ends up being. In practice, that generally means finding the right balance between:
-
Reusing standard/widely known commands and constructs, so that your scriptability "fits" with the rest of the system/apps.
-
Creating new commands/constructs so that you don't create confusion or errors by using an abstraction that doesn't really match what your app actually "does".
There isn't any fixed formula for picking the right balance between those to factors, as it really depends on what your app "does" and how you want to script it.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware