A library is a type of script object that represents a group of methods that are stored in a compiled script. Just define several useful functions in Script Editor then save them with a meaningful name, like WebLib. You can then call these functions from other scripts by using the load script osax:

set wlib to (load script "macintosh hd:ASlibraries:WebLib")

Let's say the WebLib library has a method called httpGet. The wlib variable now refers to the WebLib script object, so you could call this method with the code:

wlib's httpGet(  )

You could also save WebLib as a stay-open applet. As long as the library applet is running (with few performance implications as a small applet will only use several hundred bytes of memory), you could call its functions from another applet with code as spare as:

tell app "WebLib" to httpGet("my.yahoo.com")

AppleScript will be able to "find" the WebLib applet a lot easier when you try to compile the latter code fragment if WebLib is already a running process.

There are several good reasons why you might want to have code libraries running on your machine, with a principal one being code reuse. Let's say you have five separate applets that each performs various mathematical calculations. Instead of defining the same math subroutines inside of each applet, you can keep these subroutines stored inside a single library, from which the various applets can use these methods after loading the library themselves. It is inefficient to include the same subroutine definition inside five different applets. Another reason to consolidate code inside of libraries is to "separate the things that change from the things that stay the same."^[1] For example, a system administrator might have created several applets that occasionally have to be updated to accommodate the changing requirements of their network users. In designing the scripting system, the scripter places all subroutines and/or properties that do not change inside a library, which can be called from the applets that do have to be rewritten and compiled once in a while. It is inefficient to keep recompiling the unchanged source code, except in response to the rare occasions when it has to be changed. So the rule of thumb when designing large AppleScript systems is to take the things that do not change and put them in a library that will be loaded by other applets.

^[1] I derived this nice principle of program design from the very good book, Thinking in Java by Bruce Eckel.

Remote Script Object and Library Access Script objects and libraries can also be accessed remotely over TCP/IP networks. This is a very powerful feature of Mac OS 9 and later versions called "program linking via IP." For example, if the WebLib library were running on another Mac on the network, you could call its methods from a script on another machine as long as you knew the library machine's IP address. Here's the code: tell app "WebLib" of machine "eppc://192.168.0.2" to httpGet("my.yahoo.com") The protocol "eppc:", by the way, stands for "event program to program communications." The possibilities are limitless. Chapter 25, is devoted to scripting the File Sharing control panel and program linking.

Libraries are AppleScripts that can feed their functionality into other applets. Along with user-defined subroutines, you can also place code that automates certain programs inside of libraries so the code can be used by all applets. For example, you might define a library subroutine that will tell Photoshop 6 to open and save an image file. Any time any other applet needs to save an image file in Photoshop, it just uses this external library function, instead of having to define the method itself.