Re: AS Library Question
Re: AS Library Question
- Subject: Re: AS Library Question
- From: Chris Page <email@hidden>
- Date: Thu, 17 Dec 2015 05:53:00 -0800
> On Dec 10, 2015, at 3:00 PM, Shane Stanley <email@hidden> wrote:
>
> So I take it the answer to my implied question -- "I'm wondering if your latest assessment is based on more recent experience or technical insight" -- is no. Thanks.
>
>> On 11 Dec 2015, at 6:41 AM, has <email@hidden> wrote:
>>
>> but since that's never been a requirement in the official developer documentation most apps - and even Apple's own NSAppleScript class - have spent the last 20 years happily loading scripts into a single CI and aren't about to change just because some Apple engineer says something on a little-read mailing list.
His comments about the relationship between OSA component instances and script library loading don't seem to actually indicate a technical problem, just a personal discomfort with it conceptually, because it is more flexible than Mach-O frameworks.
Script Library Loading and AppleScript Component Instances
==========================================================
As mentioned in one of my earlier replies on this thread, library scripts are essentially identical to any other script once they're loaded into the AppleScript runtime. Apart from the search path used to locate them, they're just like scripts loaded with “load script”. Scripts are loaded into an instance of the AppleScript runtime (aka “component instance”), and OSA supports more than one component instance within a single Unix process. So script libraries are just working the way scripts work in OSA and AppleScript.
A component instance is a self-contained “universe” that contains objects, some of which are scripts, and some of the scripts may have been loaded from a file found by searching the library search path, or via “load script”, or by compiling it with OSA (or OSAKit). Nothing in one component instance can see anything in any other instance. So, it simply follows that a script (whether or not it's a library script) in one instance can't see a script in another instance, just as if they were Mach-O executables or frameworks loaded into separate processes.
However, OSA and AppleScript have an advantage over Mach-O frameworks: if you wish, you can create multiple instances of AppleScript within a single process specifically to separate a set of scripts--whether they're library scripts or not--from one another and let them have their own universe to themselves, without having to fork another processes and use IPC to communicate with them from the client.
This means that if you have libraries with properties (“state”) that change values, you can have multiple AppleScript instances that each have different values for those properties and they won't interfere with one another. Five clients of a library in component instance A see the same library state as each other, whereas another five in instance B may see different library state from those first five, but the same state as one another.
Note that most clients only ever create one instance of AppleScript. Applets only have one, for example. Script Editor stands out because it creates an instance for every script document so they are independent of each other, which makes script development easier. In particular, it means that if you run a script that uses a library, and then you modify the library and run a different script, the second script will pick up the current library version from disk without interfering with the first script, and the first script will continue using the version it loaded (until you recompile that script, which gives it a fresh component instance, causing it to reload all libraries).
This apparently gives has the willies. I cannot understand why. AppleScript is a dynamic language and runtime that is more flexible than Mach-O, and it is not bound by the limitations of Mach-O loading. And the library mechanism is quite simple and straightforward, and behaves essentially like any other script loading mechanism.
> Actually, NSUserScriptTask (et al) was introduced in 10.8 and promoted as the alternative at WWDC. Indeed, it's the only way for apps in the App Store to run scripts.
NOTE: has's point about one component instance vs. multiple component instances within an application process is orthogonal to the issue of app sandboxes and running scripts in separate processes.
[Puts on his “Chief Pedant” hat.] NSUserScriptTask is not the only way for App Store apps to run scripts. App Store apps can run any script shipped with the app, or any script the user chooses, but if the script is run within the app's process, that naturally means it's subject to that app's sandbox and entitlements. That may be perfectly fine in many cases. However, if you want an app to be able to run completely arbitrary user-supplied scripts without limiting them to the app's capabilities, then you must use NSUserScriptTask to run the script in a separate process that doesn't have a sandbox.
--
Chris Page
The other, other AppleScript Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden