Re: Script Library caching
Re: Script Library caching
- Subject: Re: Script Library caching
- From: has <email@hidden>
- Date: Wed, 27 Jan 2016 21:47:02 +0000
Jörgen Stahle wrote:
To explain my question… "So is there a way to reload a script library immediately after an update of it?"
I want to distribute some applescript code – used by several applescript applications – as a Script Library. This code might be updated every now and then, and I wan’t to use the changes immediately in the referring apps, without any need to restart them.
Without knowing details, it's impossible to give exact advice, but some
general thoughts...
If you make a change to your script libraries, I'm pretty sure you'll
have to restart AS-based apps for them to see those changes. The AS
interpreter doesn't expose the APIs you'd need to reload those libraries
in-situ, never mind doing it in a way that is guaranteed to be safe.
Bear in mind that dynamically *re*loading code into an already running
process is one of those tasks that looks simple on paper but very
rapidly becomes a Non Trivial Problem when you actually try to do it.
(e.g. Consider a library that returns objects which the rest of your
code shares: what happens to any extant objects when the code and
context that birthed them suddenly vanishes from the process?) You might
want to consider if this is something you genuinely require, or if
you're just being unnecessarily clever for the sake of it when a far
simpler solution would do. So honestly, if you _can_ solve the problem
with a simple app restart, that's what you should do.
If you absolutely must reload certain behaviors on the fly, I'd suggest
you use `load script` for those, packaging them as self-contained
plugins that live in their own dedicated folder which can be monitored
for file updates via e.g. Folder Actions. Alternatively, you might
package those behaviors as separate stay-open applets which your main
app launches when it needs to send them commands. You'll need to give
some consideration to error tolerance, designing your main code to deal
with e.g. the possibility of an applet being quit in the middle of
performing an operation, catching the disconnection error, and trying
again. Fault tolerant systems are often built to operate as collections
of distributed processes, where an individual process can fail or be
restarted without affecting data integrity or reliability of the system
as a whole. But you're talking about significantly increasing code
complexity for a problem that's most trivially solved with a quick restart.
If you're concerned about important data being lost because your current
app keeps it all in-memory, you might want to consider moving that data
into an external store; e.g. OS X includes PostgreSQL, which is
extremely robust and well supported (although you'll need to find an
ASOC-friendly framework to talk to it). Or, if your app needs to be
constantly listening for incoming AE/HTTP/etc requests from external
clients, maybe you want to split that interface into a separate
background process that can stay constantly running and simply puts new
requests into a temporary queue while it's waiting for your main process
to restart.
Lastly, if you're serious about this stuff, there's no shortage of
literature and advice out there (good and bad) on how to build high
reliability systems. Cliff notes version: generally the right way to do
it is to accept errors and restarts are an _inevitable_ fact of life,
and so engineer your system to cope with process failures while still
maintaining service uptime and data integrity. And once you've built a
system like that, the need to do live *in-process* updates tends to go
away by itself anyway.:)
HTH
has
_______________________________________________
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