Good morning. Welcome to session 106, Apple Script Update. Apple Script is 10 years old. It's mature, it's powerful, it rocks. And today we're going to share some of our plans on what we're going to do to make it even better for software developers and scripters. And so to kick it off, I'd like to introduce the manager of the Components and Scripting group who recently celebrated 25 years at Apple. Please welcome Mr. Chris Espinosa.

Thank you, Jason, and welcome everybody to yet another year. I just want to say that I've done a lot of things in my 25 years at Apple, and I have never been in one job for more than three years except for this one. And I think this is my fifth consecutive developer conference delivering the AppleScript update. And as long as you don't get tired of it, I won't get tired of it.

So it's our annual overview of what happened in the last year with AppleScript, what the current state is, and what we're going to do next year. We're going to review the changes since the last developer conference, since 1.7, I think, was the last version that was current as of this time last year, and look forward to what's coming up in AppleScript 1.9 in Jaguar, which is on your developer preview CD, and AppleScript 10, our new architecture.

What you're going to learn in this session is three things, mainly. There are some changes in the Apple Event Manager that any Apple event client application, that is, any scriptable application, is going to have to be careful to understand. There are going to be some changes in Apple Script 1.9 that you'll need to be aware of. And I want to show you what you'll be able to do with the new architecture when it comes out in Jaguar.

Brief review of the technology framework. AppleScript is a middleware layer that sits on top of Apple Events that it relies on for inter-application communication and is used by both the Cocoa and Carbon environments. AppleScript is usable by both Cocoa and Carbon applications, so it really doesn't matter which side of the fence you're sitting on. AppleScript Studio, which you'll learn about in a session later today, is, in fact, a very big, very sophisticated Carbon application that you can customize-- a Cocoa application that you can customize with AppleScript. There's also a parallel version of AppleScript in the classic environment. There is AppleScript parallel versions for every version of Mac OS 9 up to 9.2.2 and for classic that we're trying to keep version for version compatible with AppleScript on 10 for a very limited time. It won't be much longer.

What I want to do and what I want to do every year is thank you all for shipping your scriptable applications. It's been a great year. Every one of these applications either uses AppleScript, is scriptable, or deals with AppleScript, like firing off scripts in some way. And these are all Mac OS X applications that have shipped or been revised in the last year. And I want to thank all of you for your great work in shipping these.

But there are two things that have been very, very fulfilling. On April 29th, coming back on a Monday from a vacation, I read maxscripter.net, and this is what it said. I'm going to quote. Apple script application updates. The phrase has taken on a new meaning over the years. What used to be an occasional update announcement for commercial applications or a scattering of rewrites and enhancements to script packages and Apple script examples has grown to proportions of such magnitude that less than 48 hours of cyber absence has left our editor scrambling to catch up on all the AppleScript updates that transpired over the weekend. When Jason said, we're hot and we rock, he's not lying.

This is great stuff. The second thing is that I ran into Mark Alldritt, who is the head of late-night software and the developer of Script Debugger. We were standing in the back of Hall 2 listening to another presentation, and he turned to me and said, you know, over the last six months, My sales are way up, with a sense of wonder and astonishment in his voice. I think that's really great. The customers are out there. They're using AppleScript. They're using AppleScript on Mac OS X. They are buying script tools. They're downloading stuff from the web. AppleScript is happening, and it's happening on Mac OS X. And a lot of that has to do with some of the great applications. I'm going to bring Chris Nebel up to help me show you a couple of the ones that have come out.

Now, I go way back with Outliners, and if you know the name Dave Weiner, you know that Outliners and Macintosh and Outliners and AppleScript have a long, long history. One of my favorite Outliners was an application called first Fair Witness and then Info Depot, which was the first great scriptable Outliner program. It died a sad and much lamented death, but the Omni people have come back and have come back with a great version of OmniOutliner 2.0 with a terrific object model and terrific scriptability. So what we're going to do here is we're going to populate an OmniOutline with an AppleScript. And we need a large and fairly interesting data set. And the data set we're going to take is a QuickTime movie. Now, Chris can play this movie. This is something that I shot with my little digital camera. A time lapse of sunset, the moon transit, sunrise in the desolation wilderness up in the Tahoe area.

And we're going to take some data from that movie that QuickTime Player provides us, and we're going to put it in an outline. And it's a very simple loop. That's not the right script. It's not the right script. That's too simple a loop. Make movie outline. There we go.

Now, this is a better loop. This walks through track by track, frame by frame, the movie in QuickTime Player, and generates data rows in the outline and populates it. So when Chris runs this script, he can click over to the outline and see that it's busy populating the OmniOutliner with information on each frame. So this is fast, it's efficient, and if you want to create outlines out of large data sets, OmniOutliner is a great way to do it.

Now, it doesn't just do that, but OmniOutliner has a script menu. So if you go back to the script window... and drop that go to checked frame script into the OmniOutliner scripts folder. When you go over to OmniOutliner, you look in the script menu, there's suddenly a new script in that menu. You've checked frame 17.

and go to checked frame, you look over in the QuickTime player window, and that script tells QuickTime player to go to that frame. So you can go back and forth, script OmniOutliner and have OmniOutliner script other applications. This is a great example of the kinds of things you can do with scripting with a well-scriptable application. So thank you to the Omni people. OmniGraffle also has tremendous scriptability and is really worth looking into.

The second thing we're going to look at is a little beta that somebody emailed me about called QuartzDraw. And if you remember MacDraw, QuartzDraw has a lot of the look and feel of MacDraw, but it uses the Quartz imaging engine. So it can do all sorts of wonderful things like translates and rotates and 3D skews and transforms. So we're just going to... And it has a good scripting for all of those capabilities. So we're just going to take a little document here and do some transforms on it manually, then open up a script, script. Show you the script, and all it does is it does a, a, a rotate and a transform on the first object in that window, repeatedly. So when you run it, So anybody who wants to take this and do a 3D breakout in Apple Script is perfectly free to do that. So these are the kinds of things we're seeing just over the transom without heavy evangelism from us, without us going and beating people over the head. We're getting great scriptable applications on Mac OS X. It's something we haven't seen in years in the Apple Script front, and I really appreciate it. So thanks, Chris. Thank you.

Okay, let me do a recap of the last year. We shipped AppleScript 1.6 in the first version of Mac OS X, and that's pretty much what we talked about at the developer conference last year. We shipped AppleScript 1.7 in Mac OS 10.1 and in Mac OS 9.2.2 in the software update, though not in the 9.2.2 that ships on machines. or shipped on machines.

The first version of 1.8.1 you're going to see was in the December 2001 developer tools, and that slide is wrong. It shouldn't say Jaguar, and how that got through QC, I'm not sure. 1.8.1 first shipped in the December 2001 developer tools, and 1.8.2 shipped with the April 2002 developer tools, and you'll see that in the April 2002 developer tools in your CD. That's the current version. We have a version 1.8.3, which has some very minor fixes to 1.8.2, and it's going to ship, we believe, next week as individual software updates for both Mac OS 9 and Mac OS X. On the Mac OS X side, what 1.8.3 does is it delivers the current version of AppleScript and AppleScript Studio to end users. So if you're developing AppleScript scripts or AppleScript Studio applications with the April developer tools, this will be what you need for deployment. And on the Mac OS 9 side, 1.8.3 solves the severe performance problems with certain applications that we started to see on Mac OS 9.2 and 1.7. And on both versions, it fixes some crashing bugs with Unicode and some problems with Unicode text. We think that this is going to be a solid release that we can sit on, and it helps us build for Mac OS for AppleScript 1.9, which is what you see in your Jaguar developer preview.

So let's talk about OSA scripting in general in Jaguar. There are really four things to talk about. First is there's a whole new Apple Event Manager in Jaguar. It's rewritten from the ground up. It's got some significant changes that you need to know about. The API is primarily the same, but it really operates in a fundamentally different manner. Second is there's a lot of scriptability enhancements in the entire operating system, and we're going to show some of those to you. The third thing is that you may be surprised to see when you open up Script Editor or Script Debugger in Jaguar in your developer preview, the pop-up menu in the bottom of the window that lets you choose your scripting languages comes with the operating system with two different scripting languages, AppleScript and AppleScript 10. They're different.

They're for different purposes. One is shipping. One is essentially a developer tool for you to use and start to play with. And AppleScript 10 is the new architecture, new foundation for AppleScript in the future. We're going to be dwelling a lot on that. And the fourth thing is AppleScript Studio version 1.2, and Tim Bumgarner is going to be talking to you about that this afternoon. So let's talk about the Apple Event Manager.

The big change in the Apple Event Manager is that handles are dead. As we warned you three or four years ago, that the AEDESC data structure no longer has a data handle, but this opaque type. And the opaque type happens to be a handle up through Mac OS X version 10.1. It is no longer a handle. It is a private opaque data type that is flattened, is not handle-based, doesn't use the old Mac memory manager, and is much, much more efficient.

The important thing about that is that the data in an Apple event or the data in an AE desk now can be referenced directly rather than having to be copied when that event is moved from place to place or when you extract information from event. By saving the steps of copying the information over and over when you create and access Apple Event Descriptor records in Apple Events, we're saving a tremendous amount of time. And when we move events between applications, we're actually using Mach shared memory to move the event from one application to another so it doesn't actually get copied moving from application to application. The second application just gets a reference to shared memory with the first application. The event is already there. And we're seeing up to 1,000x performance increase in large events going back and forth between applications.

This is a significant change that's really going to revolutionize the way you deal with Apple events. Thanks. To deal with this, most of this is transparent. There are only a couple of APIs that have been added because there's the significant inconvenience that you can't just lock the data handle, double-D reference, and index into it in order to get your information out of it because it's not a handle anymore. So there are a couple of APIs that help you deal with that. In getting information, normally you just do aegetdesk data pointer or you copy the information out. There is now an additional API. If you don't want to access all of the information in a descriptor, you can call the AE Get Desk Data Range API and give it an offset, and that just gives you a piece of the information. So if you know, for example, that your payload is a C struct and you only want a field of a C struct, you can use the AE Get Desk Data Range in order just to get some bits of data out of that descriptor rather than having to copy the whole thing into a struct and then index into it if you're only going to get a few bytes. The second thing is if you want to, if you've already got data somewhere and you want to create a descriptor with that backing data without copying it, there's a new mechanism in the Apple Event Manager called AECreateDeskFromExternalPointer where you just pass the Apple Event Manager a pointer to your data, and it says, okay, I'll just use your data. I'm not going to copy it. And it expects you to make that, to retain that data for the life of the descriptor, you provide a callback, and when the Apple Event Manager is done with that data, it calls your callback, and you can release it. This is very useful with, for example, sending the data from CF types in Apple Events. So with these two, you're going to be able to deal with Apple Event descriptors much more efficiently, with fewer data copies, with less memory usage, and with much, much higher performance. and I'm going to go ahead and close the meeting.

In the Apple Event Manager, we're defining a couple of new low-level data types that we're going to be using fairly extensively. We already defined from the Apple Event level and going down the type Unicode text, which is traditional UTF-16, the full Unicode representation. We're finding that a whole lot of people use UTF-8 as a shorthand because it's generally more compact when you're dealing with generally Roman character sets. And it can be used as a substitute for ASCII or ASCII can be turned into it fairly easily. So we're making type UTF-8 a low-level type in the Apple Event Manager with coercions to and from Unicode text. We're going to talk about the migration of the whole family of text types because there are now way too many of them.

Chris Nebel will be talking about that in the AppleScript 10 portion, but for now, UTF-8 will not be a first-class type in AppleScript. Unicode text will be the type in AppleScript, but UTF-8 is going to be a fundamental way of sending information back and forth between applications and sending information to AppleScript itself. There's also a new time data type which is the ISO 8601 time. Those of you who are writing applications that talk to the Darwin kernel or to Mach are going to be dealing in type 8601 times quite a bit, and so we're providing an Apple event data type for that format and automatic coercions between it and the traditional Carbon long date time. So these are two new types that you can use in your applications.

You can put information into Apple events in these formats, Extract them in these formats, and the coercions will happen automatically. The other important thing about 8601 time, it has time zone information, which long date time does not have. So if you deal in time zones, you want to use this data type.

So here's some things to watch out for in the new Apple Event Manager. It's not a data handle anymore. You can't cast it to a pointer and make believe it's a handle. It just won't work. The Apple Event Manager will throw exceptions, and your application will halt. This is not something I recommend shipping to users. So you can set it to null. You can check for null. But otherwise, you need to deal with that as an opaque data type and use the Apple Event Manager. That also means that if you are accustomed to having a complex Apple event data type, like a list or a record in an AEDesk, you can't get the data of that as raw data anymore because it's not necessarily a flat structure. What you have to do is use the APIs. You can get the data of an AEDesk if it's a simple structure like a C struct or a stream of information, but you can't get it if it's a complex Apple event structure. You have to use the Apple event manager. And if you want to get that in order to save a list to disk or to put an object specifier on the pasteboard, you have to use the streaming APIs to do that. You can't just get the data, flatten it, cast it to a pointer or something, and then put it on the pasteboard. You have to use the streaming APIs. So some fairly simple changes, and what you're going to get out of it is a tremendous improvement in performance in Applement-based applications.

So let's talk about scriptability in Jaguar. The first piece of good news is that Folder Actions makes its return in Jaguar. We finally got the support we need. Thank you. It's not quite functional or fully built yet on the developer release CD that you have, but we will have full folder actions functionality in, and it's even better than before because folder actions will have a full object model, not just those procedural calls in order to add and remove folder actions from a folder.

There are significant improvements in Cocoa scripting, and if you are writing Cocoa applications, I highly recommend the Cocoa scripting session that Mark Piccirilli is giving tomorrow morning. Go to that. There's a lot of good things going on there. There are some new scriptable applications in Jaguar and improvements in a lot of scriptable applications. The address book that you saw Steve demo at the keynote has a very good, strong object model for scripting, and that means that the underlying database that all of the applications that use the address book use is accessible by all of your Apple Script applications, including all your Apple Script Studio applications.

That's going to be very powerful. Mail has some improvements in scriptability. The new Sherlock model has a completely new scriptability model. Apple System Profiler has been rewritten from the ground up, and the scripting has been made much more sane. Speech recognition is scriptable. The Digital Hub, which... Has anybody seen any of the Digital Hub features demoed? Ooh, we get to demo them first. There is a new set of control panels called-- or preference panels called panes.

pushups for using the wrong name. A new set of preference panes that control your, Macintosh has the hub of your digital world, and all of those preference panes allow you to execute scripts when things happen. And that's very cool. We'll show that off in a minute. And we have the initial support for scripting the preferences panes with a plug-in architecture that we're gonna show you as well.

Let me talk about AppleScript 1.9, the AppleScript engine that ships in Jaguar and that you have on your developer release CD. It's the ongoing evolution of the AppleScript 1.x family. That means that compatibility is paramount, and we're working primarily on compatibility, efficiency, and fixing bugs, and accommodating the changes in the Mac OS X platform. And I have some very good news for you on that front. We have almost finished our transition from Mac OS 9 to Mac OS X with the AppleScript core engine. And that means the number of changes we have to make to accommodate things like POSIX paths and FS refs and new process model and things like that, that's almost done. So the number of changes in AppleScript 1.9 is very, very small. We're concentrating mostly on bug fixes. There are a couple of new things that are just tunes and tweaks. But we are putting very little feature development and very little architectural changes into the AppleScript 1.9 family. That means you can rely on it for delivering solutions to your customers without having to go through this version munch that we've had for the last year and a half or two years with new versions coming out every three or four months with radically different sets of features and ways to implement things. So the good news is on the AppleScript 1.9 side, things are quieting down quite a bit, and it can be a reliable, stable platform for you to deliver scripting solutions to customers on. We think that that's crucial for getting the publishing customers onto Mac OS X. Now they've got Photoshop. Now they'll have a good, solid version of AppleScript. We think that that's going to rock. The only real change that you need to worry about is that when we introduced Unicode text and Unicode object specifiers, for historical reasons, They came through to your scriptable applications using the key form form absolute position, which some of you sent me emails saying, why is this happening? This makes no sense. It's text. It ought to be form name. And I made some wussy excuses as to why that's the way it worked. And we're going to change it.

So if somebody has a class name followed by a string in Unicode text that creates an object specifier, when that's sent to your application, that's going to come under form name. And so in your cases to handle form name, you should expect that the selection data, the SELD field, is going to be Unicode text if the source was Unicode text. So that should simplify a lot of your things. Now, your application may also run on previous versions of Apple Script where the form name is always type char and Unicode text will come through for form absolute position, so you're going to have to have some transitional cases for a while, but this is the more sensible way to do it.

Some other things that we're doing in AppleScript 1.9, we're supporting system preferences plug-ins, and we'll show you the mechanism by which we're doing that. There aren't any on your Jaguar CD, but you will start seeing them come out with the Jaguar ship. We are simplifying the way you address the system events application. It used to be you just told the finder things, and we automatically redirected the right stuff to system events. Some of you have started saying tell application system events. We're going to try to simplify that and just say tell system, and that will invoke plug-ins.

It'll invoke system-level things. It'll invoke the kinds of things that you don't really want to launch a phased application in order to do. That's where folder actions lives as well.. We're enhancing the mount volume scripting edition to support everything and anything you can do in the connect to dialog in the file, in the finder, including mounting SMB volumes. So they're going to be absolutely parallel interfaces. Any string that you can type into the connect to dialog, you can put that in the mount volume command, and it will mount in exactly the same way. And one little enhancement that the speech folk will be demoing, the say scripting edition will have an option outputting to a disk file. So if you want to use that what Steve called the-- he didn't say it was crappy, but it was in his tone of voice-- if you want to use text-to-speech to generate speech to a disk file and, say, sync it with your iPod, you can do that now with AppleScript.

So to show you some of these things, Chris Nebel is going to come up again, and we'll walk through a little demo. So the first thing we want to look at is the system events application. Some of you noticed this. It was an unheralded feature of 10.1, just a little faceless background application that handled the processes class. And it's still there. So all of the things that the finder used to do telling you about processes, including a little more now. It'll tell you whether a process is a classic process or not.

are in the system events application. And for certain things that the finder used to do, if you ask the finder, it'll say, I don't do that anymore, and we automatically relay those events to the system events application. But system events is doing more now. For example, it has the full folder action suite, which used to be divided between the folder actions extension, the faceless background application, and the standard editions. So all of the folder actions events, both the events that fire handlers in your scripts and also the events you can use in order to add or remove or manipulate folder actions on folders, they're all in system events too. And as I said, we don't just have the old events for backwards compatibility. We also have a full object model for scripts in the system events. so you can make new folder actions by saying, make new folder action.

It just seemed obvious to us. Now, in order to do that, we had to have an object model for folders. And in order to have an object model for folders, we had to have an object model for disks. And, well, we might as well throw one for files in. So we have essentially replicated the finder's file, folder, disk object hierarchy as an object model in system events. And system events is a small, fast daemon that's always running. It's not showing windows. It's not finding or indexing or doing other things at the same time. You have its complete attention. Sometimes the finder may be in simple finder mode. Sometimes the finder might not be there at all. So if you want to write a script that talks to the file system, you now have a way to script the file system without scripting the finder. And that's through System Events.

You know, I didn't bet that that would be the first applause line of the speech. So that's system events. It's going to expand. System events is also the host for all the preferences plug-ins. So as each of the preference panes becomes scriptable, its scriptability is going to show up in the system events dictionary. So you'll have one place to look for all of your plug-ins, whether there are system enhancements or whether they're the preferences pane system enhancements. That means you don't have to launch preferences.app in order to change your monitor setting, for example. Okay, you saw the address book in Steve's demo. The address book's a beautiful application, and it has a very, very good scripting model. There are some very simple things you can do with it, for example, in scripting, such as using it to address paper mail. So we have here a simple document in TextEdit, And if we just run this little script, that looks up the name in the address book and pastes in the address from it, there you go. Simple as that. If you're familiar with scripting the contacts information in Entourage or in Palm Desktop, this will seem very familiar to you. The scriptability of this will, of course, expand as the abilities of the address book expands. In the disk you have, address book does some very simple things. The scriptability is simple and straightforward, But you can create new addresses, you can set the information, you can get the information, you can do whose clauses to look for the information, and what else could somebody want.

The preferences panes, as I said, on the version that you have, there isn't any scriptability or any scriptability plugins for the preference panes themselves, but the preferences application does respond to Apple Script and Apple Event requests to go to particular preferences panes. So if you have a script that wants to bring up a preference pane, for example, from help or as part of a guided thing, you can do that. You can bring up the preferences.app and make it go to a particular pane.

And finally, I want to show you the digital hub. Some of the preferences panes, this whole row in the middle, are things to do when a CD is inserted or a blank DVD or blank CD media is inserted or when your iPod is attached or when a hard drive is attached or when something else in the digital camera is attached, when something in the media realm happens. And for each of those events, there's a pop-up menu. And one of the items in the pop-up menu is run a script. And so you can attach an Apple script to almost anything that happens in the digital media realm. So the script we're going to do, are you actually going to choose the script other than open iTunes?

Show CDD page. Okay. And you really do want to attach that script. No, it's not. There you go. That's what you want to do. - The demo works better when you actually do all the steps. So now we're going to put an audio CD in. And the script will, in addition to launching iTunes... It'll launch iTunes. It'll query iTunes for some information about the disk that you inserted. And instead of just showing the playlist in iTunes, as soon as the disk shows up, it's going to take you to the CDDB web page for that disk. So this is the kind of stuff that you can do with digital hub scripting. Imagine what you can do with scripts that happen when your digital camera is attached or when you plug in a FireWire drive. So this is beyond folder actions.

This is digital hub actions. So there's a lot of scriptability. Thank you. in Jaguar. And a lot of that comes on your developer CD. We hope you'll have a lot of fun with it. Some of the stuff is unfinished, and we are looking forward to your feedback on that.

there's very little to watch out for in AppleScript 1.9 and Jaguar. Really, the main thing is that launch services, which is the underlying system API that knows about applications, is going to require that you have your info.plist entry for NSAppleScript enabled, which is normally a Cocoa-only thing. If you have any kind of application, be it Cocoa or Carbon or a plug-in or whatever, and you're AppleScriptable, you have to have the NSAppleScript enable item in your info.plist. And that's in order to show up in the choose application window. It's just one line in your infop list, a simple requirement. The second thing is what I talked about for his form name being Unicode text. And then the third thing is that as we get more and more into Unicode text and as more and more applications return it, the more and more unreliable the unencoded forms of text are. For example, the Finder is now returning encoded text from almost all operations, including the names of folders on the desktop and the names of disks. If your application gets information and you get it as a type P string or a type C string, you're throwing away the encoding. And you won't know when you get that string whether it's Japanese, whether it's Arabic, whether it's English, or whether it's a mix of all three. So the type P string and type C string types that Andy Baczorski added so carefully for us several years ago are now officially off limits. We don't want you to use them because you will get the wrong answer and you will show garbage text to the user. So stop using type P string and type C string in the automatic coercions.

And type text. Type text assumes system encoding, and in Mac OS X, there's no such thing as system encoding. You can have a Japanese, a Korean, an Arabic, and an English folder on your desktop, and you can have a folder that has all of those characters in the same name. And type text can't express that, so stop using those text types.

So that's AppleScript 1.9, a fairly simple story. What's going on? What we're doing is we're doing a whole new version of AppleScript with some significant changes in the way we deal with terminology, in the way we deal with extensions, in the way we deal with talking to classes, in the way we deal with text, and we're calling it AppleScript 10. And we think that this is what we need in order to bring a truly first-class scripting environment to Mac OS X. And here to talk about it is the lead engineer of AppleScript 10, Chris Neville.

Thank you, Chris. I'm going to set up the demo. Oh, good. My mic is actually working. Okay, the future. What's in store? Well, quite a bit. And as it turns out, most of it has been driven by what we've heard from you, the developers. So what have you been saying? Cripe, cripe, cripe, cripe, cripe, cripe, cripe.

From application writers, we've heard that when you start off, it's too hard to write terminology. You've got AET resources. And if you're doing Carbon, you've got ScriptSuite and ScriptTerminology files. And there are very few tools to help you deal with these things, and they contain a lot of internal redundancies that make them kind of hard to edit. And it's just generally not very nice. Once you get past that and you start trying to implement your scripting, you say, this is hard. The system doesn't give you a lot of support. We actually don't get this from Cocoa people. Cocoa scripting is actually pretty good. There are a few holes, but they're filling them in. In general, life is okay. But Carbon scripting, the only help you get is Object Support Live, which doesn't really do very much for you. There's an awful lot you have to do yourself, and it's very hard to get it all right, and a lot of people don't. And if you are doing an application with plug-ins and you want to try and make those plug-ins scriptable, you say, "This is really hard." In fact, it's almost impossible. Object Support Live actually gets in the way, so you have to do all your scripting yourself if you want to do it at all. And even then, there are terminology management problems that there's really no straightforward way around.

And if you're writing Apple scripts, you typically notice fairly quickly that Apple script doesn't support its own object model. That means that there are various simple operations which are sort of implied in the language guide and which do work in applications, like making new elements, deleting them, moving them, using whose clauses, that just don't work on built-in Apple script types, like lists, records, and strings. They should, but they don't. OSACs and scripting additions are one of the major extension mechanisms for Apple script, but they're really very limited. you can only define verbs. You can't define objects, so your terminology winds up being a little weird and stilted. And they're not really shielded very well from each other, so there are all these problems with them conflicting with each other. It's very hard to distribute scripts that rely on them because of accidental conflicts. And finally, AppleScript isn't really very internationally aware. It's still kind of stuck back with the, you know, type text, type P string, type C string world, where there's one system encoding across the entire system, and that just doesn't work anymore. So we're actually addressing all of these.

Here's how. For terminology, we're defining a new XML-based format, which is much more expressive and we hope much easier to edit. We are allowing terms to show up without four-character codes attached to them. This turns out to be important for a couple reasons. We are introducing a new framework called Carbon Scripting, which will make writing scriptability for Carbon applications a lot easier. We are supporting scriptable plug-ins. And to address all the language issues, we're introducing AppleScript 10, a major revision to the language itself.

So the terminology stuff, what we've got are what we're calling scripting definition files, SDFs for short. They're a superset of the AET. The intent is to make them your one-stop shopping point for everything about your application's scriptability. That means not only are you defining the AET-like stuff, like the actual scripting terms and the four-character codes if you need them and simple comments, but also complete documentation and implementation information about what methods in your program to call in order to do all the things that your dictionary says you do.

Because they're XML, you can edit them using any XML editor you like, whether it's a super spiffy validating one or some stone knife and bearskin kind of thing like VI, like I use. We're supplying tools so you can generate old-style things. So you can start using these things today and have the tool grind out an AET resource or a script suite and script terminology file. In the future, you'd start using these things with Cocoa Scripting to generate the data tables that it needs to drive your application.

So what does one of these things actually look like? Well, here's a very stripped-down example. The structure is basically AET-like. You've got a root dictionary element. Dictionaries contain suites. Then suites contain verbs, classes, and enumerations. So you can see a verb here. The name is the actual scripting term that shows up to the scripter, in this case, save. You have the code, which is the Apple event code. There's a definition for the direct parameter type, and then a parameter with its own name, code, its type. And this particular one is marked as optional.

So let's take a little closer look at a class. One of the cool things about SDEFs is that they support directly a number of things that are sort of hacked into AETs, like inheritance. So we actually say, you know, here's a class. Here's what it inherits from. You, of course, define elements. Elements define what accesses they support. And you go on and define properties. There's a read-only property there. That's what access equals R means. We also support write-only properties, which AETs don't. Those show up in passwords and things like that. You can actually say that explicitly now.

So how do you use one of these things? Well, again, let's look at the current world. What you start off with in your source code is typically, for a Carbon application, an AET res file. So you build that into an actual AET resource, which gets fed into the AppleScript compiler so people can actually compile scripts. And the AET typically has nothing to do with your application's implementation. On Cocoa, it's a little different. You have script suite and script terminology files. Script terminology goes into the compiler. script suite goes into your application to drive your actual implementation.

So in the new world, you start off with an SDEF file and then use the tool I mentioned called SDP to generate either an AET.R or script-sweeten-script terminology. And then everything works the same from there. In the future-- You can start using SDEF to generate Carbon scripting information, which have a more COCO-like scheme. They drive both the compile and your application. And Apple Script 10 will actually understand SDEFs directly, so you don't have to go through the intermediate step of an AETE, which tends to throw away some information.

So talk is cheap. Let's see a demo. We'll get Chris Espinosa up here. Thank you. So what we're going to do is we're going to open up one of the example S steps, which is on the system. This one is the-- what a monitor's control panel would probably look like.

there. So here it is. There's an application object to hang everything off of. It has display elements. If we go down a little bit, you can see the class display. Classes have a synonym. Again, an explicitly supported feature called screen, so you can use either term. Screens have their own elements, resolutions and refresh rates. And they have a bunch of properties. An interesting thing to notice here is the property types.

A type can be a primitive type, like an integer for brightness, or it can be another type defined elsewhere in the SDEF. For instance, current resolution is of type resolution. If we scan down a little bit, resolution is another class that we've defined here. Fairly straightforward system. So this is all very nice, but it doesn't do us a lot of good with the current tool. So let's turn it into an AETE. So to do that, we'll pop back to the terminal.

run SDP. The minus FA means spit out a AET. Yay. So let's take a little peek at that. generated. And, yeah, it looks pretty much like an AET. Seems fine. Okay. Get out of there. And now I'll res that into an actual resource. Yes, okay. And take a look at it in Script Editor with a dictionary viewer. Hey.

so now it's by a similar trick for a Cocoa application we have a modified a slightly modified version of the internet connect application which is a a nice small simple Cocoa application uh... if we pop open the apple script folder there we've secretly replaced the script suite and script terminology files with an SDF.

Let's see what happens. But before we do that, we'll look at the Targets pane. And we've defined a shell script build phase to actually call SDP twice to spit out these script suite and script terminology. So if we build this, That was very quick because we didn't have to build any of the actual code. And then we open up the products and drill down inside.

And there are our script suite and script terminology files that are generated for us. And they're pretty much exactly the same as the ones that we had written by hand. So these are XML and I think the originals were the old style text P lists. There you go. Thank you, Chris. Thanks.

Okay, codeless terminology. So there are two reasons that this turns out to be important. One is for plug-ins. One of the big problems with trying to do plug-ins right now is because of how AppleScript works. You have terms and you have codes. And AppleScript doesn't actually store the terms when you compile a script. It actually stores the codes. And then to display the script, it uses the terminology again to map back into the terms. So you have to maintain this very strict one-to-one mapping between the terms and the codes. And if you ever mess that up, then things start getting a bit confused. And if you have third-party plugins, it's very difficult to maintain this. Either you have to... Essentially, you have to ride herd on everybody and make sure that, by God, everyone uses the same codes. It's a huge pain and often doesn't work anyway.

The other big problem is that some services that we would like to talk to don't have four-character codes. They never did, and they probably never will. And specifically, we're talking about web services. Trying to get everyone out there on the web to add four-character codes to all their WSDL would be like trying to teach the proverbial pig to sing. It wastes our time and annoys the pig. Thank you.

So we're making them optional. If you have simply a term, that is what AppleScript remembers. And suddenly, there's nothing to have a conflict with, because all you've got is the term. And if two people use the same term, it's the same term. And who can tell? Now, this only applies to four-character codes as they apply to scripting terminology. The AEDESC descriptor type, which is four-character code now, that stays a four-character code. We're not messing with that.

So, like I said, you can define a four-character terminology with no codes. This is one of the points behind SDEFS is that, gee, we can have optional attributes in there. One of the optional attributes is the code. AppleScript 10 knows how to deal with these things. It will read terminology with no codes, and it will send out new codeless events. So instead of using a four-character code for, like, the event type or a class code in an object specifier, it will use the name instead. This is kind of like the PSBR events and UserF mechanisms that we use today. And we'll be providing a library that parallels AEDataModel.h, so you can do all the interesting things with codeless events. 1 Okay, Carbon scripting. We really like Cocoa scripting. We like the things that it does for developers. And there's nothing really like it in Carbon right now. So that's kind of the point to emulate this. Because not everyone can use Cocoa. Not everyone wants to use Cocoa for a variety of reasons. So this is a flat C API.

Unlike Object Support Live, it's built around object method callbacks, not just accessor routines. And it does a lot more for you than Object Support Live does. It will work with either AppleScript 1 or AppleScript 10, but it is a Mac OS X only API because Mac OS 9 So here's what the current world looks like. On the left, we've got object support lib. And what you do is you install a bunch of object accessors. And then when an event comes in, you have to field it in your application.

You figure out what it is. All the verb logic is actually handled in your application. You call down to OSL to actually resolve the object specifiers, if there are any. It calls back to your object accessors as much as action happens. You do some more stuff back in your application. And okay, everything works with a lot of effort on your part. Cocoa is a lot simpler. You feed it configuration data in the form of the script suite file that tells it how various events map to your implementation. And then when an event comes in, Cocoa fields it and figures out what to do and starts calling your methods and everything happens. So this is the model we want to emulate with Carbon scripting. So again, you have the configuration data, which is generated out of your SDEF. I suppose if you really you want to generate it yourself, but why would you? With a straight C application, of course, you haven't got any objects in the implementation sense. You just have a bunch of functions, so things are a little more complicated than Cocoa would be. In C++, you can start talking directly to your model objects methods. Again, the events are fielded by Carbon scripting. It calls your methods. A lot of stuff happens for you.

When you want to define an object, you start off with the SDEF. You lay out the terminology, the codes if you need them, all the inheritance and containment relationships, and all your properties, and the supported verbs. What is your object responsible for? How does it know how to do? And for each of these, you would define a method to call to actually do that.

You pump all that into Carbon scripting, so you have all these functions for getting contained elements, getting and sending properties, the verbs you support, make, delete, save, whatever. And then Carbon scripting will do most of the rest for you. And one of the cool things is that if you want to, you can be incredibly lazy. Given a thing which gets all the elements of an object and property accessors for those elements... Carbon scripting will do get, count, and exists of any access form for you. So index, ranges, whose clauses, the ones you didn't even know about, like random element. All happens for you. Now, it won't necessarily be very efficient about this because it's operating on sort of minimal information. So if you think you can do a better, faster job, feel free to override these, but you're not obliged to.

So, scriptable application plugins. Carbon scripting plus codeless terminology pretty much give you scriptable plugins. Like I said, Object Support Lib kind of gets in the way. First off, there's the code term mapping problem, which that's what codeless terminology solves. The big problem with Object Support Lib, well, there are two of them. One is that you only have one accessor for all the properties of an object. So, it's very hard for someone to come in and add new properties. The other thing is that it knows diddly squat about verbs. All that happens in your application. So now it's your responsibility to provide a framework to allow people to extend that.

Carbon scripting takes care of that for you. Like I said, it's all table-driven. And one of the things that it does is it allows someone new to come along and sort of apply an overlay table. It actually works very much like an Objective-C category. And as far as Carbon scripting is concerned, it's just one big happy class. And, okay, so some pieces actually come from your application. Some pieces came from the plug-in. It doesn't care.

All right, I'm rushing a little bit because we're running short of time. AppleScript 10, big features, support for codeless terminology, so all the stuff we just talked about actually works, support for Unicode source, so you can actually compile any language you want, and it stays in that language.

Thank you very much. One of the big problems with AppleScript right now, thank you, it's all driven off your current language preference. So if you're a Japanese user and you write something in Japanese and you give it to someone who doesn't have Japanese set as their primary language, it all turns into gibberish. Lovely. And we're supporting AppleScript, plugins to AppleScript itself. These will gradually replace OSaxon as we know them today.

So, Unicode scripts. Strings and comments, full Unicode. Don't have to worry about it. Identifiers will still follow the current rules. So, upper and lower case, English letters, numbers, underscores. We might do Unicode identifiers later. Makes the parser really hard. Not sure about that. The other thing is that there are too dang many string classes right now.

There will be only one string class and it will be Unicode. So there is no separate Unicode text class. We'll still understand it as a synonym, but means the same thing. So let me get Chris up here to do a quick demo of this. We have here - oops, as soon as I change screens - a Unicode script.

So this is a pretty simple, stupid thing. It just makes a bunch of folders in the finder based on a list of strings we've got. And we've got a pretty crazy mix here. We've got Japanese, Korean, Arabic, Hebrew. I apologize to any Arabic or Korean speakers. I don't know them well enough to type anything coherent, so they're total gibberish. But there's just no way this would work in AppleScript 1. At least one of these, and probably three or four, would all be turned into garbage. However, if we run this with AppleScript 10... I think you're gonna need a space there. - I think so.

It actually maintains all the languages intact, we hope. And there it goes. Thank you. Thank you, Chris. Okay, AppleScript plug-ins. Whoops, got to change screens again. *sigh* Keep forgetting I'm responsible for that. So the API we're using will be quite similar to Carbon Scripting, hopefully nearly identical. There's some differences because you're actually talking directly to AppleScript instead of an application now. The big thing is that you can actually define first-class objects. You can find real objects with properties, with elements. You're not just limited to verbs anymore. And the framework will provide object model support for you in much the same way that Carbon Scripting does.

You can also extend existing objects. So if you feel like adding some new properties to the string class, You can do that. It should be very cool. Things to keep in mind, you're extending Apple Script itself, not applications, which means you can't use these things to hijack applications the way you do with scripting editions today. The other thing we're going to be doing is we're going to require scripts to actually say which plug-ins they want. There will be a standard set that you always get, of course. But beyond that, you have to actually explicitly say, and you will get those and only those scripting editions. So this will make life slightly more difficult. You have to think a little bit more about what you're doing. thing, but it means you have a completely reliable runtime environment. No one can come along later and just, "Oh, you happen to be writing on a system that has Akua whatever installed and you didn't." It doesn't matter to your script anymore.

So once we've got planned for Jaguar, process and file folder and disk, which we kind of pick up out of the current system events implementation. What we've got on the list, so you don't bother asking us about them, we'll be redoing all the basic types in order to pick up the object model support. We'll redo application. We're also going to do URL, XML, and streams from a variety of data sources, files, networks, and processes.

If you have other suggestions, we'd love to hear them. But that's what the feedback form is for. So, by now you're probably asking, oh my god, what's going to happen to my existing scripts? Not that this isn't cool, of course. Fortunately, nothing. thing. uh... apple script and as chris mentioned is actually separate o_s_a_ language and we're shipping them both as far as i was a is concerned these are two languages into totally separate languages that just happened to look a lot like each other uh... compiled scripts remember which one they were built with so your existing apple script one scripts stay running an apple script one and we're maintaining that and it's all about backward compatibility so you stay safe now if you want to jump apple script and and take advantage of all the features you can do that AppleScript 10 will execute most 1.x scripts as is.

We are making a few semantic changes because there are certain things in AppleScript 1 that just never actually worked quite right. They either fail or they give the wrong answer. So if you happen to be relying on the wrong answer, then you've got a problem, but hopefully you weren't doing that.

So what can you do now with the Jaguar seeds you've actually got? You can start using SDEF files. The processor, the DTD, of course, and some examples are all on the disk. So you can tear those apart, start writing your own, use them to generate your AET and ScriptSuite terminology files for your applications today. You can compile UTF-8 scripts with Apple Script 10.

Just arrange for OSA compile to get type UTF-8 text, and it'll be happy. Unfortunately, there's a bug that breaks all the coersions to UTF-8 text in the seed. We fixed that already, but you don't have that. And finally, you can give us feedback. Here, there's a feedback form, which we'll be showing you the slide for later. And, of course, you can always email us. What can you do later? When we get to Jaguar, you can use SDEFs to build, again, keep using SDEFs. You can start developer Carbon scripting. There'll be an initial SDK. And you can start testing with the AppleScript 10 beta that'll be on there.

host Jaguar, you can actually, these things will actually be for real. So you can actually ship applications that are based on Carbon scripting, and you can ship AppleScript 10 scripts and plug-ins. That's it for me. Let me get Chris back up here to say a few things about AppleScript documentation. Thank you. Thank you, Chris. Completely out of character. I'm going to run a couple minutes late for my WWDC presentation, but we have some obligatory documentation slides. These are the documents you probably already know about. Here's what's happening. Apple Events and Scripting is being updated.

The Apple Event Manager reference is going to have the new changes that we've talked about, and there are already tech notes for the AE build and the streaming interfaces, and you should look those up already. XMLRPC and SOAP, there is a very good document an introduction for that, for both using it from raw Apple events as well as using it from Apple Script, and you can go look for that. The Apple Script language guide is finally being updated. It's jumping all the way from 1.3.7 to 1.9, ignoring all of the intermediate releases. We don't have a schedule for that, but it's sorely needed. And Apple Script 10, some of the technical documents will be available, we expect, in tech note or release note form with Jaguar, and the big documents will be available after Jaguar. So I want to sum up. In Jaguar, in what you've got, Apple Script 1.9 is coming.

It's got more scriptability through the system and minor enhancements in the language and runtime. Apple Script 10, you are having your first developer release. It's not very functional, but it points the direction. You can start using the SDP and SDEF stuff. You can start playing with Unicode text. In Jaguar, you will have more full SDK with the Carbon scripting stuff, and this is the future direction for us. we expect a full-blown release with your plug-ins and applications in the next release after Jaguar. Test your application for Apple Event compatibility. Make sure that you're not dereferencing the data handle. Take advantage of the better Cocoa scripting that you'll learn about in the Cocoa scripting session. Start writing your terminology using SDEFs. That's a lot easier than building AETEs or ScriptSuite and Script Terminology files. And go to the Apple Script Studio intro at 3.30 today. Go to the Cocoa Scripting Session tomorrow morning at 10.30. Come to the Feedback Forum tomorrow afternoon at 3.30. Let us know how we're doing. Jason Yeo is in his fourth, fifth, sixth year as the Apple Script Evangelist. John Montbreon is our Apple Script DTS Engineer. He's been churning out some great tech notes for us recently. You can look him up. And I am, as always, your humble servant in the Components and Scripting Group. Um,