Hello I'm Eric Bailey. The engineering manager for the iTunes U team. I'm excited to be here today to talk to you about iTunes U. I have an early question here, how many of you are representing an education institution that has an iTunes U site already? Great, great that's a good number.

We're going to cover kind of a natural progression here, we're going to start the high level, kind of talk about the current uses for iTunes U, how it's being utilized in campuses today, give you some concept's that are out there to describe iTunes U. we are going to go in to planning the site and discussing what considerations you should give in terms of organizing your content and we're going to get in to some code, we're going to look at some examples of how you integrate iTunes U with your online systems and then we'll go in to some web services which are new just as of March, and Thomas Burkholder will come up here to describe to you what you can do with web services to go deeper in your integration with iTunes U.

So first I'd like to talk about what we just released in the past few weeks, we added a section to the action store for iTunes U content, so now you can navigate at the top level for many who were in the iTunes store to see our public space for iTunes U content, there's a link there on the left hand side, you go in to the iTunes U area, the iTunes store, we've got a featured area for a great educational content that sixteen schools that worked with us to get content to their iTunes U site have published today.

You see examples of some of the work that our editors choose to feature, you see the top downloads and you've got a list of the universities that are involved along the left. You click on one, you go right in to their iTunes U site and now you see everything that they've posted and the site that they've chosen to put together within iTunes U.

We're really excited about this because it gives all the visibility of this content the same levels of all the other content within the store. You can search in the store and find contents of whether you're searching for an artist, you find U2 and Coldplay, you can now enter in your favorite educational subject and hopefully find some great content from one of these schools. We index this data, all the tracks and data to a greater degree than we do in a pod cast directory so you can search through the comments and descriptions and all the meta data that is there in the iTunes U content that these schools have posted.

Another example and really the more common case we've been developing for the last two years in terms of how iTunes U is being utilized on campus is to create a space to control access based on groups and students who are enrolled in specific courses. I'm going to use this example, the Cupertino University University, it's a fictitious(sp?) university we've put together that we do a lot of testing with and we'll show you how we build a site and how we plan this site out using this example.

This is a site where we're going to put together controlled access to some specific pages and so this is our Cooper team of universities welcome page, we call it the top level of this site and you draw down to a course page and this is what you see.

You get something similar to an album page with in the iTunes store where you can have different tabs that organize the content within this page. You have some course art work and a place to enter a text description and a place to put in links that link back to other online systems within your environment and other topical websites related to this area of study.

Another example of an iTunes U site that we used to control access is internally at Apple. We use iTunes U to deliver all the content for Apple developer connection and wwdc presentations. So if you go in there to download a wwdc session, you're actually utilizing the same technologies of iTunes U.

So I'm going to tell you what I'm planning in the site. Constructing all the pages and uploading content in to various areas and how you should think about getting involved with that when you're planning your iTunes U site. We've designed iTunes U templates to be very flexible, but we've done so in a way that we feel is user centric.

We want to make it very dynamic so that the content that the user has access to is right there at the top level and the page builds itself based on what credentials and permissions this user comes in to iTunes U with. So, in my example here we have three sections, one called courses, one called events and one called campus community.

The course is meant to be dynamic so that if I have access to just these four courses that's all I see. Behind that structure there may be hundreds of courses that would be visible to an administrator, but for the user who logs in they just see these four, because that's what they have permission to do.

Behind iTunes U, is basically a hierarchy like in data structures that we're all familiar with, you have a site at the top level of the site, the welcome page corresponds to the entry point for that site. You sub divide your site into sections, so divide that in to courses, you can add other elements to this, you can create sub menu pages and we'll go in to that a little bit later and how you can manipulate that and edit the XML to do so.

I want to define the section, make sure that's clear that you gotta section here with four courses in it, so a section is a way of grouping several things together and why do we do that? You want to have the visual element in the iTunes U template. It also allows you to put permissions on that entire section, so that if we have a section like this called events or campus community we can assign a permission to that whole area and give a group of users access to everything with in it.

Some other terms you'll hear me use are course and course page. The page we saw earlier, we call that a course page. A tab is a way of sub dividing content on that course page, in to separate areas so that when you click on it, a tab, the track list updates to show the content that's been put in that tab. And a track, the track may be audio or video, you can also put pdf in to iTunes, we might use that word track interchangeably with any of those media types.

So this structure that you see on the right when you fill in the meta data about those objects you get the site structure on the left and as we plan our site we're going to assign different permissions and roles to those users and how we want to access those areas of our site.

So in the example I'm putting together here through my slides, we're going to consider four different roles. The site administrator is myself, I should be able to see everything, I have all of the super user capabilities if you will, to manage the site. Second is instructor, I want to have pages within this site for instructors to be able to manage the content that goes in to their course page. So they should be able to go in to certain sections and have the ability to edit, but not the entire site.

For the students, I want them to have access just to those courses they are enrolled in and they should have download access to the content that is placed in to those course pages and tabs within those course pages by the instructor. And then last, is the word all here public visitors interchangeably all is the term for the credential within iTunes U that gives access to anybody to the public.

So we're going to take part of our site and make it available to the public because it's content that we want to share not only with our campus community but really anybody interested in Cupertino University university and finding out more about it. So when I say public visitor, when you see the credential that says all, they are synonymous.

The levels of the access that you can put on to different areas of iTunes U, it can block access. So you may need to set up a rule that says I don't want this user to have access to anything below this section of the tree. You can assign download access which then gives them the ability to browse and download any content within that section and in some places we have the ability to put a drop box or shared access so that if you want to set up a tab or a course where you want students or other roles, you can create a role for a teaching assistant or somebody else to be able to put content in to those areas, you can do that. There's a specific level of access defined for that purpose and then the highest level of access is edit, to be able to fully edit things within that page, the titles, the descriptions, create tabs, delete tabs, add content, delete content.

So these are the different levels of access that you can assign within iTunes U. And for my example, I'm going to put those together with the four roles that I want to manage with in my site and this is how it lays out and maps to these different roles.

So, I've been using this word credential and permission and what does this mean in terms of iTunes U. Well one of the things about iTunes U is that iTunes U is not managed the identity of the people that enter the iTunes U site. We expect that your campus your institution to implement a way of passing us information to tell us what that user should be able to do and the mechanism for that is by passing a credential.

There for we don't have to know anything about the users individual identity, we just need to know what they should have access to. So you pass us a credential, combine that with an access level, know access download and now we have a permission for a particular area within that site.

This allows us to have an architecture that deals with privacy concerns that many of your institutions might have so you don't have to pass this to any of the individuals, private information. So that, when we say credentials, that's what we're talking about. And a permission is a combination of that credential on an access level to assign to a specific part of the hierarchy.

So here's my hierarchy again, what I want to do now given the four roles I'm considering is put a credential around these two sections and all the content beneath that in those course pages and I want to give that the, a credential and then I'm going to assign a credential to each of the four courses, a unique credential actually two credentials per course.

So what it would look like in terms of the strings that are going to be passed to iTunes U when you authorize a user, is your going to pass that string on the right if you want to give somebody access to those sections and your going to pass one of these two credentials depending upon the course.

The first one being for a student that has access to the love and despair in poetry class and the second would be the instructor for that class and you can have of course many instructors if you want, you just pass the credential for instructor when your authorizing that user in to iTunes U.

So how do we go about doing this? When you go in to iTunes U as an administrator, you have access to several administrator functions, one of them is edit access and when you click on edit access you get this page. Remembering that the site is a hierarchy, you want to make sure that your at the top level of your site and this pop up list in the middle of the page defines where you are in the hierarchy, we're at the top level of the Cupertino University site and by default, there's no access for the all credential.

So what we're going to do is we're going to change that credential, to give it access so that public users can enter our site. So once we do that, set it to download all the sudden now, that entire hierarchy we just saw is going to have public download access.

Now that we've done that, we need to then might go down within the other courses and block public users from accessing those courses. You can do so, this way, you navigate to the course you click edit access again and you'll notice that because we set that permission at the top level it has cascaded down to this part of our site, now we're going to override that value. We click the pencil to edit that and we set this course to have no access.

Now we have blocked public users from visiting these course pages. We then need to go and give those specific credentials for that course access to this course. So down at the bottom we're going to enter in a custom permission and this is where it's part of your job to define what are these strings we're going to define access to these different areas. What are these strings that uniquely identify a student or instructor and their affiliation with the course from your own information architecture.

So you click edit, you change the access level and you enter in the unique string that defines that credential. Now we have some other ways of defining credential I'm not going to talk about in this session but that are in our documentation so that you can do variable substitution and create credentials that are based on the information that you pass in to iTunes U.

Well once you've changed that access, to edit, now I have done what I need to do to give an instructor access to edit that course. So now that I've done that let me go through a couple of different cases. First example, the user on the right is an instructor.

Their an instructor for two courses and so their going to, when your system has authorized a user in to that system into iTunes U, your going to need to pass us those two strings that they are instructors for and then by default their going to get these last two credentials.

There's four credentials that iTunes U assigns by default based on how you entered the site. Everyone gets the all credential and that's how we know that we have a public visitor potentially. If you've authenticated through your school's authorization authentication authorization mechanism for any iTunes, entry in iTunes U, your also going to get an authenticated credential.

So those two are ones that are built in to the system to help make it easier to assign these very high level group designations that will make it easier to determine what's public and what's private for anonymous visitors. So this user's coming in with those four credentials and because of that now you can see what the site hierarchy on the left there that they're going to have access to two courses and the events and campus community section. So what does that look like? When they load iTunes U, this is the page that they see, the events section only has those two courses. Here's another example, a student, they just come in with one credential, when they load that page that's what they get.

So we've put together a basic iTunes U site that has a few public sections, courses that are based on credentials and this is the typical set up that we've seen a schools utilize as they begin to use iTunes U and experiment with all its capabilities is set up a few courses and set up a few areas that are generally open for other's to use and really sharing techniques about pod casting or recording some campus events and sharing that with all the users.

So now I'm going to talk about how you get further in to this, we've seen kind of how you would use it, how you might plan out a site. How are we going to integrate this with your institutions identity management. As I said, iTunes U doesn't manage identity so there needs to be a sequence of events here to transition the user from some online web page in to iTunes U, and so this sequence starts out within the web browser so I've got the icon for Safari here to represent the web browser. There going to be some where on line and your own course management system or some other page that they click on a link to access iTunes U.

So that page needs to submit a form, do what ever it needs to do. The user may already be in a session for web application on your site, but basically if you know that, then your requesting access to iTunes U, your campus, something on your campus needs to respond and say this user should have access to iTunes U and these are the credentials we're going to pass for this user.

So this is, this is where you come in, where you need to write some custom logic to be able to determine what that user should be able to do. Once you have that and you know what credentials that user should carry with them, you forward that on to the iTunes U server and you pass that in a secure way, which I'll go over in a second. If it all passes our checks on the iTunes U server side we send back a URL that contains a session identifier that will establish a session on behalf of that user.

You can then forward that back to the browser and if the user has iTunes installed they'll hand it off to iTunes and iTunes U will load the appropriate page within the iTunes U environment and if they don't have iTunes it will tell them to install iTunes. So that's the sequence of events that happens when we're, what we expect to happen when your campus begins to integrate their authentication authorization in to iTunes U. So let's step down in to step two which is really to detail that's matters most.

What is it that we're passing from your campus to the iTunes U server? This is the transfer authorization data for iTunes U, we need to see an identity, a time stamp and a set of credentials and the identity is optional. What do we use identity for? I said you didn't have to pass it but if you do pass it, it helps us keep track and add to our logs what user did what and if that's important to you, then you can add an identity and it will display in the usage reports what users did what.

It also helps if your using the shared and drop boxed features, so that we can automatically insert meta data that says Jane doe uploaded this file on May eleventh two thousand and seven. So if you pass identity those are the sorts of things we use it for, as I said it's optional. What I've seen some schools do is instead of passing it in a clear readable format like this, they put it in to a hash that they understand how to interpret and that it's opaque to Apple.

The time stamp and then a set of credentials, I've got two credentials here separated by a semi colon in the middle. You take this information, you sign it using a shared secret that we provided when we provisioned the iTunes U sit for your school and send it over SSL to our servers.

That establishes the session. Let me step through this, I know a lot of people have been working to get their schools integrated with iTunes U and some of the details of creating these measures and passing it, I've seen a lot of people stumble and come up short in getting this to work and so I want to step through some code here. We provide some example code on the iTunes U support site and the key part of it here I have on this slide which shows how to build this credential string and sign it. So I'm going to step through this.

So first off we're putting together a string of credentials. I'm expecting that hearing this variable, but part of your job is to determine what groups is this user a part of, what affiliations do they have with any courses and to put that in to this variable, but ultimately once we do that, we want to URL and code it so that we can pass it safely to Apple with out any lunging of data and then we get this type of an out put. So we first build that part of the string and then we want to move on to identity.

If you have identity, you add this in there again it's optional, you can skip these two lines of code if you wanted to. I have it here, so I URL and code that data and then that gets appended and then I need a time stamp. The time stamp is important because the transfer of this information is only good for a short amount of time, ninety seconds. So if this message is not returned to the browser and the user doesn't establish a session at iTunes U, it's invalid.

You have the time stamp and now you've got that appended on as part of the string and then the last part is to produce a signature. And in java this is pretty simple, there's a function for doing this, you provide the data you want to sign and the key and it returns it and we append that to the buffer and we end up with this. You pass that to iTunes U and you'll get an authorized session and in this case for two instructors we have edit access to those courses.

So in implementing this transfer logic, there's a couple of steps I've seen people make mistakes on. The server time is not accurate, we talked about adding that time stamp, that time stamp needs to be in sync with our servers so we synchronize to a gmt, using the ntp protocol, I suggest you do the same thing with your server so that we'll never have our servers get out of sync on the clocks and then the symptom of that is I hear some people say that our script is working and now it's not, what happened? And if you use the debug page, I'll talk about in a second, you'll see probably that the times got out of sync and there's clock drift going on and we're not accepting the message because we think it's invalid.

You notice that we URL and coded those values. It's important that they're getting coded so that the data doesn't get lunged by a proxy or some http transfer of information in the middle. I seen credentials not separated properly by semi colons and it's just real common where the strings are really close but they don't match, your missing a semi colon or a semi colon is a period or something like that, so copy and paste errors, so the thing to do is to use our debugging page.

So when your transferring information to iTunes U to establish a session, you can append a debug suffix. It comes with the information that we provided when we provisioned your site. You add that on to the URL that you post and then you get the debug page instead of transferring to the iTunes U and the heart of the matter is at the bottom line.

It tells you exactly what you should have access to do with these credentials. You have browsing, downloading, editing, uploading and editing access. If you don't see that and you're expecting to get in as a sited administrator, then something went wrong and so read carefully above on the debug page and you'll be able to see what happened.

Alright, so, we've covered planning the site and how to authorize an authenticated user in to iTunes U. In March we had some web services and so I want Thomas to come up here and describe those for us.

Thanks Eric. My name is Thomas Burkholder for those that don't know me. We're going to talk about iTunes U Web Services today and what iTunes U web services is. We'll go to the big idea here.

The big idea is and the main idea of web services is that there are many things with web services or with iTunes U that are not trivial to do with UI. And there are many times that you want to integrate your iTunes U site with services that are not within Apple's control, so if you want to integrate with an (inuadible) or other systems your going to want to do bulk uploads or bulk provisioning of the site, it's a little bit hard to do with just a UI, so this was our first attempt and our initial foray in to the world of web services, APIs and probably not our last, there will be more. So I think I've covered everything on that slide so moving right along.

So what it is and what it isn't, just to make it a little more clear. You can make wholesale editions to your site, deletions and changes, you can access some features that are not yet exposed in the UI, occasionally there are some things we find easier to expose in the XML and not in the UI, at least at first.

It's a way of understanding your site a little bit better, you'll find that the complete hierarchy of your site is a little hard to understand since your looking at it page by page in the UI, but when you open it in XML, I don't know if you're an engineer like me, you find that a little bit easier to understand when you can list everything with it's parent and it's very easy to understand, you'll see that as we go to that slide. Couple things that it's not, it's not an archiving mechanism and it's not a hierarchical file system. It's not a truck, more like a series of two, had to throw it in.

So what that means for not an archiving mechanism and not a hierarchical file system is there are things , your going to look at this and your going to see its very hierarchical, it's very logical how it's laid out. But it doesn't work exactly like you might expect a file system to and so just bear in mind that although some of this looks like that it's not the same thing.

And its not a full archiving mechanism yet because we've not yet output the actual bits of the content that you've uploaded, there's some bandwidth issues with that and it's another idea so its inadvisable to consider this a mechanism to archive your site, you should still keep your content locally and locked to rely on us to archive it with this.

Okay the basics. We'll talk about a few things before we go right in to code here. The objects you can manipulate, you can manipulate courses, groups, permissions, credentials and tracks. If you looked on the original slide that Eric showed you, you'll see that we we're looking at a whole site and within that site you saw several sections and within the sections you saw courses and for the moment what we are manipulating is courses and the things underneath it which are groups and a group in principle matches up to a tab if you've seen a tab on the screen.

Well why didn't we call it a tab? Well it's just an engineer kind of thing, if we called it a tab then if we change the representation on the screen sometime in the future we give you an alternate representation, you know then we would have a bad name so we call it a group, it makes it nice and generic.

Permissions, credentials and tracks, Eric covered permissions and credentials a little bit earlier. Those are items that either apply at each different level of the hierarchy that provide access to different groups of users and we'll go over some of that also as w e go through as well. And tracks as well as I think he also covered.

The basic operations that you do on these objects, there's one special operation called show tree and that shows your entire site. Outside of that, everything falls in to one of three categories, which are add methods, delete methods and merge methods. So for each of these kinds of objects you have add methods, delete methods and merge methods with a few exceptions, but in particular you have things like add course, delete group, merge track, stuff like that, so it's very logical, you know your operation your name and your operation and your object and all these web services, they fall in to these categories. There's a few things that you won't see there, that you will see on the hierarchy it self and the output, things like site, sections and divisions, we don't yet have ways of adding, deleting or merging those, that will come eventually.

The inter action mechanism it self, everything we do at iTunes U for now with changing these, changing your site with web services, api and for other uploads that you'll see is all through a standard http upload mechanism. So if you're familiar with how that works and the http protocol, it's just like that.

But the URL that you upload to, you have to get because this has to be secure, you have to get through another mechanism we return that to you through the get upload URL api mechanism. This is covered in the documentation and we won't cover it in very much detail here because it's a whole subject on to itself.

But suffice if I say, I'd just like to transfer a script that you seen Eric go over, it has to be signed and when it is signed properly and its got all the right parameters, you get an upload URL that you can then upload to and you can see a simple example we have there.

Just to talk a little a bout site structure as it's seen in abstract form for a second and Eric covered this a little bit as well but talking about from an abstract perspective you have your site at the root and then inside the site you have several sections and inside those sections you have courses and inside the courses you tend to have groups and inside the group you have tracks. It gets a little more complicated than that as some of you may know from seeing several sites.

We also have this concept of a division which we're introducing that terminology more at the data level than at the UI level. It just looks like another welcome page, a lot like the page you saw coming in to the site and that basically shows sort of a sub section of your site, obviously we couldn't call it a section, already had one of those.

So division idea is a lot like your site root but it's rooted inside your site and you can have several levels of these as we go three deep as you see here. So the thing to think about that is that it's something that is basically a lot like a site and it can contain these other objects.

The main take home point for this slide here is, you can't just contain any object in any other object, a section can only be contained inside a division or a site. A course is only contained in a section, groups are only contained in courses. So the very somewhat rigid structure.

We'll talk about the first directive we have here which is called show tree. Show tree is the single directive we have that shows you your entire site structure and it's integral to how we interact with the site because later on when we do all our merge mechanisms, merging is done by essentially clipping little bits out of the show tree results.

So this is really probably the most important thing to do with your site. Once you've got this working, you can really work on everything else. So there's three flavors of this. Because when I initially did this, we spat out so much data it became really hard to read and got huge files.

We wanted to be able to print it down, here and there, so we've got minimal, most and maximal and that allows us to see you know, just, just the bare bones that's the titles and the structure versus you know, a little bit more data, down to you know, just way more data than you can possibly need when you say maximal. And that's, so going over the XML you'll see here, the show tree entity, very simple.

And by the way, as we go through these examples, you'll see you know, it'll start with you know, the directive itself as if there's nothing before. You know, when you're sending an XML document, obviously you have to have this header here where it says XML version 1 point 0 etcetera.

There's an envelope around all of our directives called iTunes U document and then inside that are the actual directives and you can have as many as you want, which will be executed in series. But for the most part as we go through this, you'll see that they're just referred to you know in toto as if they're just their own item.

So this is the base for the most simple kind of show tree document that you can send, that you can upload to our server. When you do a htp upload of this, it's going to spit out the upload that we're going to show on the next slide. But because that's sort of a two step process, you have to get the upload URL and then upload it and because you do it so commonly, we also provided a shortcut which is sort of in parallel with the upload action itself. You can, if you look at the URL the bottom of this slide, you can very easily just produce this output in a single step. Because we're doing it so much.

Moving right along. The first output. So this is a very, very small representation of a site and you can see that down at the bottom level here there's a group inside the core, inside a section which itself is inside a site and this is just to give you an idea of what's going on in this very small site. We've actually occluded this group, there's a lot more that you're going to see on the next slide that goes into the group. There's just not enough room on the slide.

Other things to notice about this output are the handles. Every level of our site, every one of these objects, you know, the site and the section and the course, all of these objects have handles and that's one of the things you'll see in a lot of the directives. We use that a lot to locate these objects. It's a little bit like an inode in a file system if you're familiar with that, but it's a unique identifier for which you can identify these objects.

There will be other ways, but for now, that's what we've got. So moving into the, zooming into this group a little bit you'll see, you'll see, I wanted to talk a little bit about this permission as well here. You see, we talked about the permission a little bit earlier and it's really important to note that actually this happens at every level of the site. You can put this, this permission applies to the whole site. If it was inside the section it would apply to the section only. If it was inside the course, it would apply only to that.

But looking at the group, zooming in on the group there for a second, we want to talk a little bit about (laughs) some of what's in here. Most of these objects, including the group you know, almost all of them will have a name you know and a handle. You can kinda depend on that for everything.

Inside the track itself you can kinda see there'll be multiple tracks inside an ordinary group that have more than one track. But this one we just show one track and you can see a number of things that come out in the track display. You know, like the track number and the disk number, it's duration and things like that. So we spit all of that out.

Moving right along. Talking about a permission again, Eric covered this a little bit before, but I wanted to drive the point a little bit further home. Permission essentially binds a credential object to a folder and when I say folder here, I mean any of these objects that contain other objects in our tree. So group of course is such a section. So credential is a role describing user access.

When you add that to the access level such as no access download drop box, those things represent a permission and those permissions are bound to any one of these objects and then that, that permission is then scoped from an inherited perspective. So everything underneath that inherits that permission.

So you'll see this these permission puts a lot in your show tree outputs. So moving on to one of the most basic operations, adding objects. You can add at the moment courses, groups, permissions, credentials and tracks. Typically for an add object, you supply a parent handle and you take the handle from your show tree output at this point, you take that handle and you say, I want to add an object to this parent and when you add an object, it creates an object and it takes all of the items and the entity that you supply and adds and creates that object using that entity. So it essentially merges it in.

We'll talk a little bit more about merge later, but effectively, whenever you add, you're just saying, take this XML and make the internal object representation. We'll see that on the next page in the example. And as I mentioned before, you have to be careful about your parent. You obviously will get an error if you try and add a course for instance, directly to a site. You have to add a course to a section.

Okay, talking about an add example, we have our simple Cupertino U site here and we're going to add a course to the my courses section. This is the example before the add. When we execute this XML here, it's going to add a single course called theory of Rectophronology 210 lab, which has a single group inside it called Numbskulls, with apologies to Terry Pratchet.

So this is a very simple one and one thing I want to point out here, the add course has an option to provide a template and if you're familiar with templates in UI of the of iTunes U, with templates you can cause a new course to be added from a template set up before which is kinda set up default graphics and other things inside the course itself.

So it can often be really handy and you can do the same thing in XML just by supplying a template handle. So that's the XML we would use. After we've added it, you'll see the extra course appear under the courses, this should be my courses, but it should, in the course section it shows theory of rectofronology 210 lab. So very simple.

Deleting objects. There's no undelete. Maybe someday, but right now use at your own risk. If you delete something it's really gone, just like if you use the UI. It's no more, more or less dangerous than the UI, just bear it in mind. Typically, delete is implemented by providing the handle of what you want to delete, just like when you added a course, you to provide the handle of the parent you wanted to add it to. When you delete an object, you say what you want, what the handle is of the object you're deleting.

One thing to note, when you're deleting a permission, permissions are a little bit of a special object. They don't have a handle of their own, so you have to identify them through a combination of factors, a parent like what it's parent is and what it's credential name is. And note that delete works on nearly all objects and removes the specified objects plus all child objects. That's just like in the UI. If you delete a section, it's all gone, including all the courses in the section and all the tracks in those courses.

Unlike the UI, those tracks will not move into the trash. I believe in some cases in the UI, those tracks move into the trash. Not here. In the delete example we have here, we're going to delete the same course. Beforehand you can see that. We're going to execute this XML. This XML actually does more than delete just a single course, but that's all you'll be able to see because, the permission and the credential we're deleting are objects that are effectively invisible to the UI.

Anyway, as you can see here, when we said delete permission, we have provide a parent and a credent, parent handle and the credential name. We can actually delete that credential independently as well and obviously with the ellipses here, I'm just removing a little bit of the details, just because it won't fit on the slide. And then ultimately we're going to delete the course, just by specifying its handle. Very simple.

Afterward, that was a little bit of a graphics glitch, but you can see it blew up our course. It's gone. Okay, so merge objects. Merge is probably the most powerful concept we've got. The intention of merge is to be able to copy and modify results from your show tree operation, paste them back into a merge object directive.

So with merge, you can cause, in a single operation, you can choose to reorder courses say delete a group, add another course, things like that. Just by, the basic idea is you have your site output, you have your show tree output and if you just decide to you know, modify around and edit out what you want, change what you want and then upload it all wholesale and then the site should then look that way, which is pretty powerful. But there's some caveats.

So to kinda, to kinda drill down a little bit into what merge actually does, the first thing it's going to do when you decide to merge an object, it's going to look at properties of the object, like the name of the object and it's going to rename it to that, to that name if you've, if you've set a new name it's going to you know, change that or other items like if you were merging a track and you specified a track duration, it's going to change that. So simple things that just modify the object that you specified.

If you specified child objects and that don't already exist, then it's going to add those. So if I decided to merge a course and provide it a group inside that course entity, that didn't already exist, if a group by that name didn't already exist, then it's going to add that object.

And if you provided an object that already did exist, so if I told it to merge a course, it found that course and I specified a group in my XML and that group also existed within that course, it's going to merge that version of the group into that course as well. So this merge is very much an inherited thing. It's a recursive thing. It goes down the entire tree. So by merging a course, you cause all the groups underneath it to be merged and the tracks underneath that to be merged.

If we had a merged site, it would do everything. It would cause every, all the sections to be merged, the divisions and everything else, etcetera. But we don't have a merged site just yet. It's worth noting that there's also another thing that merge can do. If you set destructive to be true, destructive also tells it to say hey, if you see something that isn't in the XML but does exist in the site, then delete that. Not necessarily recommended, but if you're really trying to make your site look exactly like your XML, then this will do it.

And lastly, it can set the order according to the input order. So if all I change is the order of two groups within a course, when I send up the XML, it'll just reorder those. So pretty versatile thing. So we're going to go over three examples for merge and the first one we can see our before site. This is our course page, our theory of rectofornology 210 lab, with one group in it called Numbskulls.

The first example, in this first example we're going to just use merge to add a few things. We're going to add a permission and we're going to add a group. So this example adds a permission to the existing Numbskulls group and also adds a group called auto rectrofornology a primer, to the previously added course. So it's going to do two things in one operation. After we've done that, what you'll see is there's a new, a new tab, which is a group called auto rectrofornology a primer.

The other things are also there, can't really see them because, they're invisible in the UI. Second merge example. This example reorders the groups in the theory of rectrofornology 210 course. So all we're specifying here, again we're specifying the course handle as we did before so it knows what course we're merging and we're specifying the groups by name and it's going to use those names to reorder the course.

It's going to look in those, in that course and it's going to say hey, I see a group called auto rectrofornology a primer and another group called Numbskulls, but they're in a different order. So it's just going to order them this way. Very simple and you can see after we've done, it's reordered.

Here we go. We're supposed to have a zoom in on there, but we don't. Third merge example. Selective delete. This example deletes the Numbskulls group and the theory of rectrofornology 210 course, by omitting it from the list of groups. It also deletes any track objects under and that's a mis edit too.

It deletes any track objects under Numbskulls. So as you'll see, we're using the destructive option and we're specifying that we're, we're specifying our course without the Numbskulls group and that causes the Numbskulls group to be deleted. The only ones that will be preserved are the ones that are listed here.

Very simple and after we're done, you can see all we have left is the auto rectrofornology a primer group. That's about it for web services as it stands today. There's going to be a few more thing we're adding to it. As I mentioned before, we're going to be merging sites and adding, deleting and merging divisions and sections. So this is going to get more powerful.

We're going to have path based referencing. One of the things I wanted to mention was that, everything that you can see through here, we're referring to everything by handle and while every object in the system does have a handle and they are all unique, that's not really the way you want to manipulate objects in the long term.

You want to be able to reference them by some form of a past. It's a little bit like, the big, the main problem with handle here is in order to find out what object you want to manipulate, you have to show the entire tree and you know, zoom in on that and say okay, this is the object, which is not necessarily always that easy to automate.

So later on we're going to move toward this path based referencing where there is some form of a path, a lot like a file system that will allow you to navigate and specify the object that you want to deal with, based on this path. And lastly we're going to have a dtd. A dtd is just something we haven't gotten to yet and we will get to. It's been a requested by several folks. So that's where we're going. That's pretty much concludes my part of the presentation.

I'm going to call Eric back up here and I guess we'll do some Q and A. Is that the plan Eric? Some more Q and A now. Okay, we'll answer your questions.

Can you hear me? So this slide we just wanted to make sure know the URL to find all the resources for iTunes U. Documentation, sample code and other resources.

We've got many pdf's describing different things you might need to give to your users to better understand iTunes U. We have support forms there where many of you have posted questions. We try to answer those and ask you guys to help each other answer those questions as you run into common issues. And if you have any developer contact questions, there's your contact.

And I think that's about it. Let's make sure I haven't forgotten anything. Oh, following this session there is a lab. We'll be downstairs and we'll be there to answer your questions in more depth and that's following this session and most of the other sessions that we hope you attended were previous to this one, the Podcast Producer session this morning, I hope many of you saw they're really showing off a great new technology that if you're interested in iTunes U should really help you automate the work flow and the process of getting all the content into iTunes U. So yeah, that pretty much covers it.