Doh! Thanks Chris--so many details, I lost sight of this... knew the
reason was bigger than just avoiding "tell"...
I made it a scripting addition because it runs in the target
process... that gives the automatic advantage that I get independent
instances of the engine per application, one of the advantages that
John notes. If I make it an application, then I have to put some
burden on the user. That is, a client application would call my
"open" command, and I'd have to return a reference ID, which the
client app would have to pass back any time it needed to have the
engine do anything.
If that was totally unclear, here's an example. I might make several
MIDI applications using this scriptable MIDI engine. If I release it
publicly, maybe other people do to. Maybe some of these are written
in AppleScript Studio, or other means of creating standalone apps
that can speak AppleScript. As a scripting addition (either bundled
in the standalone, or the the usual library locations), these
separate apps maintain a unique identity automatically. If each has
one MIDI output port, when two of these are open, you see that each
has a unique output port--they aren't sharing one "system" port. Each
can write to its MIDI output without identifying it uniquely. When
you change the tempo of the default clock in one, it doesn't change
the other. I also made the decision to do things like, for the
objects that make sense, address things originally (if you ask for 5
output ports, you can send something to port "4", and avoid having to
deal with port identifiers; also if you don't address any port, port
1 is assumed, and since you'll normally only have one, you typically
don't need to mention ports at all in the calling parameters).
If I do this as an app, then all commands need to deal with client
identifiers. Considering that a MIDi app will open MIDI at the
beginning, close it at the end, and potentially do a lot of different
commands in between, it's a lot bigger burden than, say, dealing with
file references ("open for access..."), which typically very localized.
Anyway, I was going to revisit this issue at the "very end", but I've
made a lot of effort to minimize the scripting and parameters
required for typical things, and would like to avoid having to deal
with client references. Maybe there's a better solution--I haven't
thought about it much--but probably not.
I appreciate the input, thank you guys,
Nigel
On Jul 5, 2007, at 2:46 AM, Chris Page wrote:
• Scripting additions run in the target process, giving them the
potential of crashing the target application or subtly corrupting
user data. A scriptable application is its own process and is both
protected from other processes and prevented from damaging them
directly.
On Jul 5, 2007, at 9:32 AM, Jon Pugh wrote:
These are also strengths, depending on your intent. Being able to
run in the context of a host application was certainly more useful
in the old Mac OS, but there are still conceivable legitimate uses.
