Good morning. Welcome to session 106, AppleScript Update. AppleScript is ten 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 AppleScript 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-- Cocoa application that you can customize with AppleScript. There's also a parallel version of AppleScript in the classic environment. There's 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 it's very, very--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: "AppleScript 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 in AppleScript 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 Aldrit, who is the head of late-night software and the developer of ScriptDebugger. 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. And 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 Omni outline 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, and the moon. And 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. Chris Espinosa, Chris Nebel So this is fast, it's efficient, and if you want to create outlines out of large datasets, 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 checkedFrame, you look over in the QuickTimePlayer window, and that script tells QuickTimePlayer to go to that frame. So you can go back and forth. Script omni-outliner and have omni-outliner 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. Show you the script, and all it does is it does 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 AppleScript 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 AppleScript front, and I really appreciate it. So, thanks Chris.

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. That slide is wrong. It shouldn't say Jaguar. 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. You'll see that in the April 2002 developer tools that you have. That's the current version.

We have 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, you're going 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, Apple Script and Apple Script 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 Apple Script 10 is the new architecture, new foundation for Apple Script in the future. We're going to be dwelling a lot on that. And the fourth thing is Apple Script 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 AEDESC 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 status.

So in the first step of copying the information over and over when you create and access Apple Event Descriptor records and 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 updates. We're seeing changes to a thousand X performance increase in large events going back and forth between applications. Significant change is really going to revolutionize the way you deal with Apple Events.

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 let's talk about scriptability in Jaguar. The first good piece of good news is that Folder Actions makes its return in Jaguar. We finally got the support we need. 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 night. Go to that. There are 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 AppleScript applications, including all your AppleScript 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's a new set of control panels called-- or preference panels called panes.

We've got 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.

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." 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 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 of 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 was 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. 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 plug-ins for the preference panes themselves, but the Preferences application does respond to AppleScript and Apple event requests to go to particular preference 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 AppleScript 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. in Jaguar. 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 Info.plist, 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 up with a wrong answer. You will show garbage text to the user. So stop using type P string and type C string in the automatic coercions.

and TypeText. TypeText 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 TypeText 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. Great. 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 ObjectSupportLib, 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 plugins, and you want to try and make those plugins scriptable, you say, "This is really hard." In fact, it's almost impossible. ObjectSupportLib 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.

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, SDEFs 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 AETE 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 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 ScriptSuite and ScriptTerminology, and then everything works the same from there. In the future, You can start using SDEFs to generate Carbon scripting information, which have a more Cocoa-like scheme. They drive both the compile and your application.

And AppleScript 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've got Chris Espinosa up here. So, what we're going to do is we're going to open up one of the example SDEFs which is on the system. This one is what a monitor's control panel would probably look like.

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, currentResolution is of type resolution.

If we scan down a little bit, resolution is another class that we've defined here. A fairly straightforward system. 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. To do that, we'll pop back to the terminal.

run SDP. The -fa means spit out a AETE. Yay! So let's take a little peek at that.

Yes, okay. And take a look at it in Script Editor with a dictionary viewer. So now let's try a similar trick for a Cocoa application. We have a slightly modified version of the Internet Connect application, which is a nice, small, simple Cocoa application. If we pop open the AppleScript folder there, we'll see that We've secretly replaced the ScriptSuite and ScriptTechnology files with an SDEF.

We've defined a shell script build phase to actually call SDP twice to spit out these script-sweetened script terminology.

If we build this,

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

Okay, codeless terminology. 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. 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. You have to maintain this very strict one-to-one mapping between the terms and the codes.

If you ever mess that up, then things start getting a bit confused. If you have third-party plug-ins, it's very difficult to maintain this. Either you have 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. 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.

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 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. We'll be providing a library that parallels AEDataModel.h, so you can do all the interesting things with codeless events.

Okay, Carbon Scripting. We really like Cocoa Scripting. We like the things that it does for developers. There's nothing really like it in Carbon right now, so that's kind of the point to emulate this. Not everyone can use Cocoa. Not everyone wants to use Cocoa, for a variety of reasons.

This is a flat-C API. Unlike ObjectSupportLib, it's built around object method callbacks, not just accessor routines, and it does a lot more for you than ObjectSupportLib does. It will work with either AppleScript 1 or AppleScript 10, but it is a Mac OS 10-only API because Mac OS 9 is dead.

Here's what the current world looks like. On the left, we've got ObjectSupportLib. What you do is you install a bunch of object accessors. 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 OK, 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. Then, when an event comes in, Cocoa fields it and figures out what to do and starts calling your methods, and everything happens. This is the model we want to emulate with Carbon scripting. Again, you have the configuration data, which is generated out of your SDEF.

I suppose if you really wanted to, you could 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 object's 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? What does it know how to do? 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, makes, deletes, saves, whatever. and then Carbon Scripting will do most of the rest for you. 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 exist 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. It won't necessarily be very efficient about this, because it's operating on minimal information. 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 plugin. It doesn't care.

All right, I'm rushing a little bit because we're running short of time. AppleScript 10. The 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--is 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 plug-ins to AppleScript itself. These will gradually replace OSAXen as we know them today.

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. It makes the parser really hard. I'm 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. There is no separate Unicode text class. We'll still understand it as a synonym, but it means the same thing. Let me get Chris up here to do a quick demo of this.

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, we're I think you're going to need a space there. I think so.

It actually maintains all the languages intact, we hope. And there it goes. Thank you, Chris. Okay, AppleScript plug-ins. Whoops, got to change screens again. Keep forgetting I'm responsible for that. 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. The framework will provide object model support for you in much the same way that Carbon Scripting does. You can also extend existing objects. 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 AppleScript 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. This will make life slightly more difficult. You have to think a little bit more about what you're doing, but it means you have a completely reliable runtime environment. No one can come along later and just say, "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.

Once we've got planned for Jaguar, process and file folder and disk, which we 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. 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. AppleScript 10, as Chris mentioned, is actually a separate OSA language, and we're shipping them both.

As far as OSA is concerned, these are two totally separate languages that just happen to look a lot like each other. Compiled scripts remember which one they were built with, so your existing AppleScript 1 scripts stay running in AppleScript 1, and we're maintaining that, and it's all about backward compatibility, so you stay safe. Now, if you want to make the jump to AppleScript 10 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 script terminology files for your applications today. You can compile UTF-8 scripts with AppleScript 10. Just arrange for OSA Compile to type UTF-8 text, and it'll be happy. Unfortunately, there's a bug that breaks all the coercions to UTF-8 text in the seed. We fixed that already, but you don't have that.

Finally, you can give us feedback. Here, there's a feedback form, which we'll be showing you the slide for later. 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.

If you're using the same script as Jaguar, these things will actually be for real. 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.