Good morning everybody. So, many Cake fans out there?

Yeah!

Well, hope you guys enjoyed the concert last night. So my name is Kjell Bronder. I'm an engineer on the Podcast Producer Team, and we're going to be talking about Deploying Podcast Producer today. So as you've probably learned this week, there's really 3 pieces to Podcast Producer.

There's the capture piece, processing, and delivery. And today we're going to focus on the 2 last ones, on how you can best set up and all the best practices for setting up the best processing grid possible. And then we're going to spend the second half of the presentation talking about the Podcast Library and how you can customize it for your own needs. For the first part, I'm going to bring up my colleague, George Cook, who's a consulting engineer with Apple, and he's going to go through some of the Best Practices of Deploying Podcast Producer for you.

So please welcome George Cook.

Thanks, Kjell. So welcome everyone. I'm a Consulting Engineer in Apple Education Division, and I'm really happy to be here today to present to all of you Podcast Producer. But first, how many folks here were at the bash last night? So thank you for making it to a 9 a.m. session, first of all. And for those that didn't come to the bash last night, well, I recorded it and I put it up on the web. Hold on a second, that's exactly one of the things that Podcast Producer was designed for.

It was designed so that you can consistently take that content, present it, and distribute it to your target audience. And this is something that we see in education, this is a need that Podcast Producer is really helping to fill. Today we're going to talk about 3 critical components of Podcast Producer deployment. We're going to start with a Shared File System. So the Shared Filed System is really the heart of Podcast Producer. The decisions you make when you deploy the Shared File System are critical in determining the scalability of your deployment, high availability of your deployment, et cetera.

Next, we're going to talk about the Media Processing and Encoding engine for Podcast Producer. This is the brain of Podcast Producer. And we're going to talk about how you can best deploy that. And then Kjell and Eric will come up and join us to talk about the content delivery component of Podcast Producer. Based on Atom and RSS standards, a really exciting new feature of Snow Leopard is the Podcast Library. Because this is so important, we are going to cover that in-depth in the second half of this session. But there's one thing missing from this picture and that's you.

So I want to start off by talking a little bit about Podcast Producer 1.0 Deployments. On the business side, there are hundreds of thousands of podcasts available on iTunes Music Store in a directory. All that's available to anybody that wants to download that content. There's also a lot of private use of podcasting in business, and the example I'm going to use today is for BBC America. BBC America has a challenge. They need to get content out for editorial review so that editors either onsite or offsite can review that content, comment on it, and approve that content.

So we're going to take a look at their deployment. I'm really thrilled to have worked with many education institutions on Podcast Producer deployments in education. And in fact, we recently hosted regional conferences along with MacLearning.org. So MacLearning.org organized these conferences. They are held across the country, and you saw an example if you came to one of the other Podcast Producer sessions, when NYU got up and talked about their deployment.

We're going to take a look at another deployment. The exiting thing happening in education is that there's a real change happening, and digital content is really a catalyst in that change. And at these conferences, our customers got up and did presentations like this and talked to their peers about how content is being used by students to produce their own content.

How content is being distributed any place, any time with capabilities like iTunes U. And all of this is very exciting and it's an area that is fomenting change in education and it's really fun to work in this area. So let's talk about these deployments, starting with BBC America. So BBC America is a large postproduction facility in New York City. Like many large production facilities, they are using Final Cut Studio. They have an Xsan deployed. And to organize their content and to collaborate in work groups, they are using Final Cut Server.

However, they had 2 challenges. These reviewers, these key decision makers that need to review this content, sometimes they're not in the facility physically. The other thing that's a challenge for many postproduction environments is viewing the content in a form that their actual audience will view it in. And Podcast Producer helped address both of these needs. So with Podcast Producer, they're taking content from their video postproduction environment for publishing it via Final Cut Server into Podcast Producer.

That content is then distributed for mobile clients any place any time, iPhone, iPod Touch, and also to HDTVs that are in reviewers' homes or in their remote offices, so that they can actually view the content using the same experience, the same type of visual experience that they're actual audience will view the content in.

So this is great and they were able to do this without any crazy customization or expensive solutions. And this is how their system works. Final Cut Server has this ability to run external scripts transparently from the graphical interface. So they're leveraging that capability. It also allows you to pass variables. Final Cut Server is very rich in applying metadata to Final Cut projects and media assets. So they take those-- that metadata and they pass it into these scripts.

And they also have the option to leverage Compressor. So they use a Compressor cluster, in their case, to time code, visually time code this content. In that way a reviewer can say specifically at a specific piece of time code there was an issue that they would like to have changed. This is what their submission script looks like. It's very simple. And there are 2 highlighted areas here.

They are pulling out some metadata from Final Cut Server, and they're using that to post to a specific wiki. So they're-- that allows them to use one Podcast Producer workflow, but post it to a specific wiki that's associated with that project. That way these key decision makers can use the wiki to comment on that content, to add their comments, and to approve that content.

On the Podcast Producer side inside of the workflow, they are just taking that value coming from their production environment and using that to drive which wiki this content is posted to. So this is a very powerful example that shows you very simple integration between a postproduction workflow into Podcast Producer and ultimately to this audience of key decision makers. Next, we're going to take a look at North Carolina State. They were one of the institutions that presented academics, in this case they presented at Duke University. And they're deployment of Podcast Producer is very much a canonical deployment.

They began with Open Directory. They wanted to integrate the services that Mac OS X Server provides with their campus authentication infrastructure. So they did this by installing Open Directory Master and then they piloted Podcast Producer. They set up a Podcast Producer server and try it out. This is what many institutions do. They start off with a single server.

It worked really well, so they decided to deploy a cluster to support their media processing needs. So they deployed Xgrid and tied all those systems into an Xsan clustered file system. This allows them to scale their system up over time to meet their growing needs in terms of capacity. They also did something that I always recommend my customers do and they set up a Development and Test System.

This allows them to develop new workflows and test them before they go into production. It allows them to deploy new versions of software and test them before they go into production. This is really important in a mission critical environment where you're delivering educational content to a large audience. In their facility, they currently have 29 classrooms outfitted for capture. These systems are Mac minis bound securely to Podcast Producer and they're capturing off of the projector loop.

So they use a VGA capture device to capture everything that's being deployed on the projector, whether it's a document camera, a Windows notebook, or a MacBook. This has provided them with the flexibility to outfit all of these classrooms in a very inexpensive way to get that content, present it as they want it presented to their target audience and facilitate this change in education of any place, any time learning.

Before we get into the meat of this, of my part of the presentation, I thought it was important to go through a little checklist of factors you need to consider for your deployment.

Now first of all is how much content. How much content are you going to be submitting into your Podcast Producer system? In the case of North Carolina State, for example, they have 29 classrooms.

They-- each one is capturing content and submitting into the system. How regularly are they being used for that capacity? BBC, on the other hand, they're coming out of a video production workflow. How many of these digital dailies, shorts and full blown productions are doing and what's the length of that content.

So, how much content are they actually submitting into the system. What about this branding and dual source picture in a picture, all these great effects that we now can do in Podcast Producer automatically, what are you going to use in your actual environment? And how many versions are you going to encode? Are you going to create a version for Apple TV, an iPod version, an audio only version? All of those factors are really important in determining your computing grid and your Shared File System.

This next set of questions are related to really to your ingest network and your delivery network. So how would content-the content be captured? Are you going to be binding this camera agents like North Carolina State or coming out of a production workflow in a custom way like BBC, or perhaps you're going to have ad hoc capture from anywhere on a 3G network.

That has implications on how you design the content ingest side of your network. Where is that content going to be submitted from, on campus, for instance at NC State, all those Mac Minis are tied into a 100-megabit network. They're wired into the network, so they have a great path back to those servers.

Again, network capacity needs to be factored in to your deployment. And on the delivery side, what's the size of your audience? Are they on campus, on a college campus? Are they distributed around the world? The size of your audience needs to be factored in in terms of your delivery network.

And where is the audience, again, local, remote, where are they? So those are factors to consider and the main point here is to plan ahead. You need to plan ahead by factoring those things in before you actually deploy So now let's get into deployment. And we're going to start here with the discussion of the Shared File System for Podcast Producer. There are really 3 choices for Shared File System. The first is all-in-one.

This is where all the services run on one server. The new Xserve has a great new capability. You can boot the OS from a solid state drive and you can configure these 3 drives in it with hardware RAID to deliver that very high performance file system for Podcast Producer. This is a great setup for an all-in-one configuration.

And this would typically be used in a pilot or in a development system or for smaller implementation. If you're a small business and you need to do, you know, a few podcasts a day, this is quite adequate for that purpose. If your needs grow and you have a lot of content you produce then you might want to add RAID.

So, Apple has partnered with Promise to deliver a fully supported RAID solution that works extremely well at Podcast Producer. In this case, we're going to fully populate this RAID. We're going to use 7 drives in a RAID 5 configuration and another 7 drives in RAID 5. And perhaps, we create a RAID 50 out of these P2 LUNs, and then we have a couple of hot spares. That way if a drive fails, the system will automatically rebuild the RAID without user interaction.

This configuration is actually outlined and we have scripts to configure your RAID on our support site. So that's the all-in-one configuration. Chances are, if you're adding that kind of storage, you're probably going to have a fair amount of processing that you're going to be doing. So it's really easy in Snow Leopard to go from this all-in-one configuration to NFS. In fact when you create an all-in-one, it automatically creates the NFS infrastructure you need to add additional systems. All you have to do is bind those systems to the directory.

They automatically mount the NFS file system, and you're ready then to add extra nodes that will increase your media processing and encoding capacity. You can also add additional delivery nodes to support a larger audience. So NFS is a great configuration for the medium-sized Podcast Producer deployment. And finally, Xsan. So Xsan is what North Carolina State deployed and this is the best configuration for a highly scalable Podcast Producer deployment.

Xsan is a clustered file system. In Xsan, you have redundancy throughout the system, so high availability, multiple metadata controllers, make that Shared File System much more reliable, multiple paths, Fibre Channel paths to the data, again increase reliability. Connected to that Xsan Shared File System, you now have your Podcast Producer Servers, your media processing and encoding systems, and your content archive and delivery systems.

So Xsan is the best choice for highly-scalable deployment. Do that, you connect your camera machines, your ad hoc agents and, of course, your clients. So those are the 3 basic choices. And let's just go through an analysis of why you might choose one over the other. Well obviously if you want to deploy a single server, you use the all-in-one configuration, that's the single server deployment.

Another new feature in Snow Leopard is Express Setup or a setup assistant that gives you-- let's you choose express or standard setup. With the all-in-one and NFS configuration, you don't have to have a SAN in place before you make that configuration, so it's really easy to set up Podcast Producer.

If you want to use direct attached storage, whether it's right in the Xserve or via a Promise RAID that's direct attached, again, the all-in-one and NFS configurations are what you want to use for that. And then finally, if you want to scale this in terms of media processing and encoding, you need Xgrid, you need multiple systems, well that be either NFS or Xsan. So, this begs the question of why would you ever choose Xsan. Well the first reason is high availability. As I mentioned before, Xsan has built-in high availability. With Xsan you have this cluster file system, multiple paths for the data.

You have a very reliable clustered file system. In addition, when you deploy on Xsan, we're going to talk more about how Podcast Producer and the grid also support high availability. Another feature of Xsan is the ability to take your storage and allocate different parts of it for different purposes.

For example, very protected storage for your archive and a balance between protection and performance for your Shared File System. And for Scratch you might want to have just the fastest possible storage available. With Xsan and affinities, you're able to take a single volume and divide it up so that the most appropriate storage is used for the most appropriate purpose. It is a very powerful feature of Xsan that you don't get with those other choices.

Xsan also makes it very easy to grow your file system. Over time your archive's going to grow and you're going to need more space. With Xsan, you can add another RAID chassis to your rack and now you've grown your file system. You have more storage available for that growing archive of content. And finally, video workgroups. If you're already using Final Cut Studio and you're in a larger production environment, chances are you already have an Xsan deployed.

Integrating that video workgroup with Podcast Producer is very easy with an Xsan environment. So this Xsan is ideal if you have both a video workgroup, production workgroup like BBC, as well as the need to deploy a Podcast Producer. Let's take a look at how you would provision storage, one example of how you might provision your storage for Podcast Producer. Promise has an E class chassis.

This is the RAID chassis with Fibre Channel controllers. And to that, you can add a JBOD or Just a Bunch of Disks chassis that increases your performance and capacity. So in this example we're going to use a two drive LUN, a RAID 1 LUN, a protected LUN for metadata, that's very important, metadata is critical.

We're also going to set up for 6 drive LUNs. These RAID 5 LUNs are going to be put together into an affinity to give us the best possible balance between performance and protection. Again, we're going to add some drives as hot spares, that way if a drive fails, nobody has to go in and replace the drive. The RAID will automatically build itself-- rebuild itself if a drive fails.

And finally, we have these 3 remaining drives and we're going to set those drives up for our Scratch area. And we might want to deploy them like North Carolina State did and set up a Development and Test System that's tied into the SAN and that's its playground. That's the area that that production-- that test system is going to use.

That makes it really easy to move from a test environment to deployment all in the same SAN. And again, we have scripts that configure the E and J class chassis in exactly this way available on our site.

So after you've configured these RAIDs, it's very easy to set up Xsan.

You can do it during server installation or with Xsan admin and there's a specific option that optimizes Xsan for Podcast Producer. That's all done from the graph, from the GUI, and it's a great way to get started with your Xsan configuration. So in summary, the Shared File System for Podcast Producer should be set up to scale to fit your requirements.

If you're a small business, the all-in-one might be the best solution for you. If you're a small department in a school or a K12 school that has a small number of podcast, all-in-one is a great way to start And it's easy again to move from all-in-one to an NFS configuration. It's all set up for you.

All you have to do is bind additional servers to the directory and they are available as Xgrid nodes. And then finally for Xsan, if you want the most scalable, highest performance and a highly available system for mission critical Podcast Producer deployment, then Xsan is your best choice. There is an Xsan session following this session that's going to go into much more detail on the nuts and bolts of configuring Xsan. So if you're the person that's going to be responsible for the Shared File System, you might want to check that session out, either today or later online.

The next component of your deployment is Xgrid. So Xgrid again is the brain of Podcast Producer. It's what takes these jobs in as workflows and then distributes those workflow tasks to these computing nodes. The complexity of your workflow is the primary driver that determines what you need in terms of a grid. So I did a little stream recording of this incredible new tool that these gentlemen created for us, Podcast Composer. So Podcast Composer is this fabulous new tool that allows us to do things like import multiple videos. We can do dual source imports.

We have 2 sources of video now coming in that we want to put together into, say, a picture and a picture composition. At the edit stage, we can add intro videos with transitions to titles and have picture in a picture and automatic detection and chapter generation. And then we can export that content into multiple formats, for iPod, for IO or Apple TV and we can publish it out to the wiki, to the Podcast Library, to Final Cut Server, transfer it over to some other server for archive and then notify our target clients with iChat, email or some other service.

So what we're able to do now is build a very complex workflow with very little effort. That's incredible, and thank you very much for that capability. [Applause] So that is really great. However, this is complicated stuff that they're doing and it has an impact on your processor requirements, memory requirements, et cetera. So that needs to be factored in when you're designing your Podcast Producer infrastructure.

In Podcast Producer, tasks in a workflow that run in parallel are distributed across your grid in a round robin fashion. So these jobs are distributed round robin across these grid notes. It's important to understand when you're deploying that the fastest CPUs are selected first. So if you have a heterogenous grid, the fastest machines are going to be filled up first with Podcast Producer tasks before those lower performance servers are ever accessed. So just an important factor when you're deploying your grid to consider.

As I mentioned before, if you want to take advantage of the high availability features that are new with Snow Leopards, you need to have Xsan. So Xsan, again, is high availability on the cluster file system and it extends now to the Xgrid controller as well as Podcast Producer.

So if you have a mission critical deployment as many of our larger customers in higher education do, this is a factor that you need to consider when you're architecting your deployment. So when you're trying to figure what you need in terms of your media and processing workflow, these are some pointers.

First, create the typical workflows that you're going to use. Review them with your creative staff, make sure you're building the workflows that you're actually going to deploy. And then, submit the type of content you're actually going to use. You can't take a one-minute video and test your grid if you're going to be deploying 60-minute lectures. Test it with those 60-minute lectures. Use the type of content you're actually going to be using and test for peak load.

Typically in education, you see peaks and troughs in terms of utilization, so you want to test for the peaks, so that when you're deploying, you're successful when the system is loaded. So test for the peak load and that's also is for your consumption of content as well. So try to anticipate those peak loads-- again for example in education, in my market, at the end of the semester that's when all the students start downloading all the podcast because they're trying to get ready for exams, you need to be ready for that. During these tasks monitor your disk CPU and network utilization. There are great UNIX tools to do this. If you went to Stephen Parker's session, he's got some great stuff, and built in the server admin we have tools that allow you to monitor this utilization.

Collect and analyze your test data during this process and make adjustments to your grid in your architecture based on your analysis. And then when you go into production, continue to monitor this performance data. It's really important that you watch the system and make sure it's behaving as expected over time.

So this is really basic stuff that IT already understands. But the great thing about Xgrid and Xsan is that it's really easy to scale this infrastructure. Over time if your media processing needs grow with Xgrid, you just put another machine in the rack, attach it to the Shared File System, bind it to the directory, and now you have more processing capability available. Same thing with Xsan, you need more storage, put more storage in the rack, it's now available for additional capacity in terms of your Shared File System.

Some more pointers on the processing nodes. First of all, I mentioned RAM considerations. When you're testing those workflows, use TOP [phonetic], make sure you're not paging the disk because obviously that's going to impact your performance. You want all your loaded grid to actually be able to work in RAM. For example, we have this great new Xserves. They had 16 virtual cores. Each one of those cores can execute one of these Podcast Producer task, so one server can do 16 things at a time, it's great. There are RAM considerations with that.

A 3-gig Xserve is probably not a good choice. You're going to want more memory and in your test, you'll be able to determine that. So take those workflows that you're actually going to use and execute them on your grid and you'll know what the memory footprint you need to have is.

For NFS, we recommend that if you're under 8 nodes, processing nodes, NFS works really, really well. However, if you go over 8 nodes, then the protocol and the network start to get in the way and they become the bottleneck. So Xsan is really a better choice for a larger scale deployment.

Xsan again, in addition to providing the scalability, also provides high availability. So it's the best combination for scalability, high availability and performance. And if you have a video production workgroup you want to integrate with Podcast Producer, Xsan is just the natural choice for that as well. So again in summary, the media processing and encoding part of Podcast Producer we have to take in account the complexity of the workflows built with Podcast Composer.

What do they mean in terms of your processing needs? Take into account the round robin task distribution. How those tasks are going to be distributed on your grid and that determines how you're going to architect that grid, fastest CPUs again being utilized first. Make the best Shared File System that match for your Xgrid.

If you have-- if you plan to have a lot of Xgrid nodes, don't plan on using NFS because the protocol, the network are going to be the bottleneck. And I always encourage my customers to deploy a development and test server. In a mission critical environment, you want to have the ability to test workflows, to test new versions of software, to load test your environment, and this development and test server gives you the platform you need to do that.

And so it's something that I always recommend my customers, especially deploying larger deployments, to consider. So that's my piece of the presentation and next, again, I'm going to turn this over to these 2 extremely talented engineers that are part of a much bigger talented engineering team to talk about the Podcast Library.

Thanks George. George has been setting up Podcast Producer all over the country, and really if you have any questions about how to deploy Podcast Producer, he'll be in the Lab this afternoon. You come talk to him. So for the second part of the presentation, we're going to start looking at the Library. The Podcast Library is a brand new feature in Snow Leopard and we really think it's going to be very powerful for a lot of you. So let's take a step back and look at this. With Podcast Producer, you're going to be producing a lot of content.

And what we wanted to do is have a way to make it very easy for you to integrate publishing this content for your organization. So you may already have a particular web page that you'll be showing your content through, maybe a web portal or you may be using an external service that's going to publish the content. Well now with the Podcast Library, you can have a central repository for all of your content that all of these external services or web pages can reflect.

So the content will live and will be served up by the Podcast Library. And these external services or web pages will be able-- allow you to create a custom front-end for your content. So as I said, the Podcast Library is a central repository, we're keeping the content and the metadata in the same place.

But we're not just serving up the content in any old way. We've created this new feature, what we call smart feeds. So think of smart feeds as what you're used to in the finder with smart folders, or smart playlist in iTunes. You can create a query and all-- any content that falls in that query, in response to that query, will be served up in this particular feed. For example, you could have let's say a user feed.

So we say Professor A and all of the content that Professor A has ever submitted to the Podcast Producer system would show up in his feed. And we're leveraging industry standards, like Atom and RSS which makes it very easy for you to customize your web front-end for the Podcast Library and show the content through your web portal.

But it also makes it very easy as I said earlier to integrate with external services, because there are a lot of services out there that already know how to read RSS or Atom. And they can basically ingest this Atom or RSS and show it in a way that they're best capable of.

We also create a lot of feeds for you automatically so that you don't have to worry about setting them up. For example, when you install a workflow, we'll automatically create a feed for that workflow. When a new user submits contents to the Podcast Producer system, we automatically create a feed for that user.

And we'll be going over this in the demo in a few minutes. But we didn't just stop there. We've made it fully customizable. So you can write your own queries in a very [inaudible]-like syntax to create your own custom feeds if you have a very particular need. And we've also set up access controls so you can set up access controls on the-- on the different feeds, and we'll talk about that in the last part.

So just to come back and just to kind of make sure we're on the same page about smart feeds, I've just got a little animation here to show you how this works. So here we've set up 2 smart feeds. The first smart feed is going to serve up all of the content that is tagged with the Physics keyword. The second is going to serve up all the content that was ever published or submitted by Professor Einstein. So coming through our workflow here, we've got-- we have a submission from Physics 101 Of course, Einstein doesn't teach Physics 101 so that just goes into Physics feed.

The same is true for Physics 102, and it's going to show up in the Physics feed. But for Physics 523, Intro to Relativity, well, Einstein actually does teach that so that's-- that content is actually going to show up in both feeds. So now you really see it, and it's really just like what you would expect when you're used to using smart folders and smart playlist in iTunes. One other thing that I'd like to point out is that we're really moving towards Atom.

We really think Atom is the future for the syndication model. And one of the first reason is that Atom allows us to have multiple enclosures per episode. So for those of you who are familiar with RSS, you know that if you do-- with respect to the RSS specification, if you want to have multiple formats, if you want to podcast your content and distribute your content in multiple formats, you have to maintain 3 different feeds. So in this example, let's say I want to have an iPod version, I want to distribute an audio only version, and an Apple TV version.

I need to maintain 3 different RSS feeds. Well with Atom, there is direct support in the specification to have multiple enclosures for a single episode. So I can now have the audio only, the iPod video, and the Apple TV version in one episode in my Atom spec, in my Atom feed.

And this is going to simplify it because now you only have one feed that you have to maintain. Another interesting point with Atom is it provides a way for us to extend the protocol right in the specification. We can extend Atom without breaking the specification by declaring our own name space and we can provide you with even more information.

So when you start playing with the Podcast Library and we'll show this to you in the demo, we'll we've extended it to provide you with even more metadata than was actually-- than initially supported by the Atom spec. So we can give you information about the frame rate, for the duration, all types of different information that you may choose to use or you can completely ignore.

And if you want to, you could even extend Atom for your use case, maybe you have some particular metadata that you would like to put into the Atom spec, well you can do that. So at this time, I'm going to bring up Eric and he's going to bring you and browse through the library and show you what it looks like.

Thank you Kjell. [Applause] Good morning. The Podcast Library is the new delivery masterpiece of Podcast Producer and it makes the out of the box publishing and consuming very simple, and I'd like to demonstrate that to you. So this is the Podcast Library root catalog. This is the highest level of the catalog. By default, we've created for you a set of different catalogs for the user, for the workflows, and some others we're going to address in a minute.

And in these catalogs, you have all the feeds. For example in these feeds, you have all the different episodes, and again in these episodes you have all the attachments. One of the reason we are using Atom now is for getting this new capability of adding multiple attachments per episodes but also as Kjell explained, they have also the ability to extend it very easily by having metadata and all the additional informations. It's also super easy to use other tools such as iTunes and other aggregators to get access to these Atom Feeds.

So for instance if I subscribe in iTunes, it will automatically load the Atom feed and get some of the content for me and then every time the Library updates these feeds then tools such as iTunes are going to get notified and [inaudible] these feeds automatically for me and then synchronize with my old devices. We're creating for you a lot of different feeds, so you don't need an out of the box, you don't need to take care about that by yourself.

We create a user feed for every time you are submitting a new content from Podcast Capture, so if you're-- for the first time you're using the Podcast Capture, we're going to create a user feed for you. Also when you install your workflow with Podcast composer, we're going to create a workflow feed automatically so then you'll have feeds you could share with your students or with your colleagues. We're going to address the keyword feed, which is a great addition in Podcast Composer.

You could actually decide when creating a workflow to add keywords for every single content going to be run through this workflow and the then the content is going to appear in those different keywords feeds for you automatically. You can also generate history feeds so that you can look at all the content produced today or yesterday or the couple of weeks before. And finally, there is a pool of feeds here where you can create your own custom feeds, your own smart feeds. So let me demonstrate that and create a new user first.

Really?

OK one more time. No.

So I've just created a nice user [laughter] from our group manager. And after creating this user, automatically it's going to appear in these user feeds. Now let's create a workflow. Since I trust Podcast Composer [laughter] I'm going to use this tool.

So let me do my first workflow, create a montage workflow, where I'm going to submit some content to it. I don't want to do any specific edition here but I still want to generate a couple of different formats, and publish all the content in the Library. So here is the way you can set some keywords.

And the cool point about this is every single keyword you're going to add here are going to be set to the different generating medias that's going to be produced by this workflow. And as you may have seen before, we do already have some keywords feed here. So for example, if I like this workflow to publish the resulting media to the WWDC and also some-- to some additional things like to create a new keyword, then these keywords are going to be used to create additional feeds that do not exist. So if I do that, I need you to try it with me to deploy it to the server, if the server wants to work using maybe my account.

No, OK. So the server does not want me install anything or use my credentials, sorry for that. So-- so once the workflow is installed, Podcast Library system does generate the feeds automatically and the feeds are going to appear in the workflow feed lists here. Then it's going to look at all the existing keywords feeds and create additional ones.

And if I do then a recording with the new user I've just created as you've seen and actually uses my new workflow, the content is going to be published at the new user feed, to the workflow feed, and to those 2 different keywords, those 2 different keywords feeds.

One thing I would like to show you is if I tag this very well and curl it through the terminal, so this is an XML file using the Atom specification. This path is an actually an episode and that displays all the different information about the link to these episodes. But let me just show you instead of a catalog, some content here. So this one has great content.

This is a leaf of the library, this is the feed itself. So in this one, if I take-- if I take the entry here, you see that you have a lot of information just for one single episode. But the very interesting parts are the attachments. So now we've developed attachments based on the workflow different formats and for these different attachments, we also provide for you automatically a set of different metadata.

So if you want to build a UI on top of that or actually sync that with any of your services, you may be able to use all these informations to do something nice with it, like for example the video cut that we are using for this format. Or the frame rates, or even some old informations about the different tracks available, do you have any closed caption tracks or video tracks, audio tracks.

And we also have this new thing called PCP formats that tells you if this content is actually low complexity element or is this SD or HD so then you can know if this is actually a content you could use with the iPhone or the iPod or with your Apple TV or with your desktop platform.

And finally, all the content that is produced is actually installed on the system-- on the file system, it's not set in the database. It's not actually put in any opaque structure on the Podcast Library server. It's actually installed on the file system and read by our systems and then cached.

So at anytime you could actually look at it and remove or add any additional element. So it's in cache library Podcast Producer shared content by default. So let me just-- so in this place, if I go and look at the content here organized by years, month, and date, if you look at the content here I've created. You see that every time you submit a content through Podcast Capture, using a workflow, we're going to create a bundle.

And in that bundle, we're going to install all the different original files that have been submitted. We're going also to put all the different metadata coming from the Podcast Capture application including all the metadata that we are going to generate server side for you so we have a lot of information here that's going to be automatically added.

And finally in the publish folder, we're going to add all the different files that has been produced. So in that particular one, I've just submitted a PDF file and this was my original file, out of this, thanks to the montage workflow, we've created different videos. So we have this editing master, high quality master, but also these different formats that you've decided to create for the iPod version, for example, including the poster image so then we can have a nice image in your feeds for presenting the content. Thank you.

Thanks Eric. So what you've seen is we've been talking about feeds. And what we've really-- we really think is powerful is we're going to provide you with Atom feeds and RSS feeds. And by doing this, we're providing you with industry standards that you can now leverage to integrate with your own web pages or portals. So it's already as you saw in the demo, it already works with aggregators like iTunes or any other Atom-aware or RSS-aware aggregator out there.

You also have web applications that know how to-- that provide a specific UI for Atom or RSS. But where this really becomes powerful is if you have a particular need, if you need to present your content in a specific way, well you know how, it's very easy to do so.

You can write tailored applications or web-based applications that can now just serve as a front-end to the Podcast Library so you can provide your customers with the best experience to consume the content that resides in the Podcast Library. By doing this, we are providing you with a service and we're making it very easy for the Podcast Producer system to serve up the content that you've been producing, but we allow you to have the flexibility of deciding how you want to best show this to your end customers and to your audience. And there's also existing services out there that already know how to ingest RSS or Atom.

So that makes integrating with them very easy as well. And well we work with out own teams at Apple to make sure that this-- we followed up on the story, and we've been working very tightly with the iTunes U team to make sure that the integration with iTunes U is as powerful as possible. And what we've done is we've made it extremely easy for you now to tie in your Podcast Library feeds with iTunes U.

So for those of you who know iTunes U, before you had to go in there and create a course page and then populate it with all the metadata like the title, the description. You've provide it with maybe a logo and then you would upload all the content that you wanted to have on your iTunes U site. What I'm really happy to say is when you have Snow Leopard with the Podcast Library, you won't have to do that anymore.

You'll create what we call a feed course page and then all you have to do is copy the URL from your Podcast Library, give that to iTunes, iTunes U, sorry, and iTunes U will build the course page for you automatically. What this means is we're going to get the title information. We're going to get, iTunes U is going to get the title information, the description, the logo image from the feed and all of the content. ITunes U is going to download everything and it's going to set up a page for you.

You won't have to go in there and manually upload all the content yourself.

But even better than that, with Atom, we have multiple enclosures, so iTunes U understands this and they will automatically create a tab per format so that your user can go in and see right away what format they want.

If they want the Apple TV format, they can just click on the Apple TV tab and they will have that content there. So the iTunes U is really going to be a great-- is going to have a great ingestion story for the Podcast Library and we really think the Podcast Library is going to be the easiest way for you to get your content to iTunes U.

So let's look at-- look at customizing your feeds. We've talked about the Podcast Library and showed you how we create a lot of the feeds for you automatically. But we understand that you're probably going to have some custom needs and you're going to want to set up your feeds yourself. So you saw it with Eric. We'll automatically create user feeds for you but we create the user feed for you when the user submits for the first time.

But we also have a way for you to very easily create a user feed before that user is ever logged into Podcast Composer, or Podcast Capture, sorry.

So we have in the podcast command line tool, there is now a command called addfeed and if you just tell it the short name that you want to create the feed for, it automatically knows to create a user feed and it will do it for you. Same thing with keyword feeds, you just held the keyword you wanted to use and it will automatically create a keyword feed for you.

But if you want to get fancy and you want to do some more interesting things with the feeds and come up with some custom queries, we've made that very easy for you to. All you need to specify is the name for the feed, give it a short description, and you can specify the query with an SQL-like syntax. So here in this example you can see that this wwdc09 feed is going to serve up all the content where the episode is title, where the episode title contains the wwdc09 string.

And we have a lot of different metadata that you can query so you're going to be able to create really complex queries if you want or you have a custom need for it. You can query information like the title, summary, keywords. But there's also information about the author, so the one who submitted the content, or when the content was actually submitted with some date information. And to show that, Eric can come back up on stage and he's going to show you how easy it is.

Thank you. So I've just created a custom feed to test it and I've created a feed that actually look at all the content that Kjell and I have created so far. So this was a really simple query to look at all the content in the Library looking at all the metadata and querying all these properties to actually then generate a feed out of all these episodes. So this is the result of the feed and we have about 26 elements.

But I'd like to create one additional feed that actually restrict that query and look at all the content that Kjell and I have created that also contains the keywords wwdc09. So for that, I'm using the addfeed command line podcast-- addfeed with specific query that is looking for the authorship named Eric or the authorship named Kjell and I'm looking for all the keywords and I have particularly want at the wwdc09 query-- keyword.

So if I install this and if I go back and refresh my custom feeds, now I have my feed 2, and this feed 2 has all these different episodes that respond to the query, and I can say that I have about 14 episodes there. But I even want to restrict that a bit more and what I'm going to do is actually to look for all the content that we've created so far using this keyword but also restrict to only the content we have created for this wwdc starting on Monday. So I'm going to add the date, actually filter here, and just make sure it starts on the 8th.

And by adding this query to the server, now I have a third feed with only 10 elements and these are all the different episodes we have created in all our different presentations this week. Thank you.

So now you've seen how we've made it so you can create really easy feeds by just installing Podcast Producer workflows and it will take care of creating a lot of the feeds for you, and then if you really want to customize this, you can create your own feeds. So now let's talk about controlling access. Of course we use Open Directory to authenticate the different users and we have multiple ways. We support different authentication types.

So of course we have Kerberos, Digest, and basic auth. The one thing to understand about the Podcast Library is we control the access through the feeds. So you can think about this as maybe like the dinner sitting on the kitchen table, well if I can get into the kitchen I will be able to eat that dinner and it's the same thing with the feeds. I have access to content. I can have access to any content that I can access through any feed.

So I've access to the feed, I can then access the content. So we're not setting access controls on the content, but just on the feeds. So just think of them as gateways to your content. And we have kind of 3 different modes of controlling access. By default and what you've seen in all of the demos, there is no access control.

It's just wide open, this is what we called world access. But maybe you want to restrict access to the entire Podcast Library to a particular group of users or groups. We've made this very easy for you. And those of you who are already familiar with server admin, all you have to do is set up a service access control list for the Podcast Producer service.

So if you restrict the SACL for Podcast Producer, this also applies to the Podcast Library. So, only users who have access to the Podcast Producer service will have access to the Podcast Library. So it makes it very easy for you to lock down access to your library to user, group of users.

But then we also have what we call lock down mode. And by turning on lock down mode, what you're doing is you're enabling access controls for all the feeds. And whenever we create a feed, we create it with an access control list. And by default, that access control list is empty so that means that nobody has access to it if you turn on access controls for feeds. There's one exception and that's for the user feeds. Well when we create a user feed, we make sure that that user has-- is on the access control list, so that they always have access to the content that they have submitted.

And if you're an administrator, well that bypasses everything because you have access to see the whole system. So you can have full access to all of the feeds and all of the content. The idea behind lock down is that you have to give explicit permission to a particular user or groups for them to have access to a particular feed.

So this provides a very granular way of setting access controls. We've seen that you can have it world access or you can lock down the whole systems to a particular user or groups, but we've also have-- have a way of getting very granular about it. I'm going to walk you through that now.

But before, we're talking about feeds here. But feeds are just another resource type for Podcast Producer. Cameras, workflows, and feeds are all resources that you can set access controls on. And for the Podcast Producer system, this access-- the whole access control model is the same for all 3 resource types. So as I said, by default for the feeds, everything is world accessible.

But if you set a SACL for the Podcast Producer system, you're basically locking down the whole Podcast Producer system for whoever is in that service access control list. But you can also set access controls for particular resource types. So, not for the resource, but the resource types. So this means that I can say that feeds are access-- are world accessible which is by default, but that for cameras and workflows, users have to be logged in and that they're-- we're going to enforce access controls for those 2 resource types.

But then of course you have multiple instances of all of these resources. And we've also made it so that you can set access controls on each individual resource. So we think we have a really granular solution that will fit all of your needs and that you can decide what type of access controls you want to set.

And I'm just going to walk you through the decision graph that happens on the Podcast Producer systems so you can understand how we decide and what kind of enforcement we're doing to detect if the user has access to a particular resource or not. So when a user comes in, the first thing that Podcast Producer system is going to check is there a SACL enabled for the Podcast Producer system. If there is and the user isn't in the SACL, we deny an access.

If there is-- and there, then we'll just continue our graph. So the second question we're gong to ask is is there a resource-- is there an ACL enabled for that resource type. Are we enforcing access controls for this particular resource that they're trying to-- the resource type that they're trying to access.

So are we enforcing access controls for feeds, for example. If we're not, then we can grant them access. If we are, we're going to ask if that particular user has access to this particular resource that they're trying to access. I think the easiest way to show you this is to show you in demo again. So Eric is going to walk you through and show you how we can set the access controls for particular feed.

OK. So anyone could use the Library by default.

If you want to restrict the usage of the Library for everyone, which means to all the user you have in your phone directory system, you just have to go and start your Server Admin, pick the server, go in Access and select the Podcast Producer service here. And by adding users or by adding groups, you're going to restrict the usage of this service to some of the users you actually want.

For example here, if you would like to open it to everyone that's in your phone directory, you just had everyone a group and automatically this is going to restrict your Library to all your users. If you'd like to even go further and lock down your system by specifying a group of users or specific groups for specific feeds, you'll have to enable ACLs at the whole library level. So for that, we have 3 command lines.

The first command line is it gives you the ability to actually enable the ACLs for the lock down strategy on all the Library, and this is going to enable the lock down for the feeds. Once you have them that, by default, all the feeds are going to be restricted to for the administrator and only the user feeds are going to be useful, are going to be accessible by the user itself as well as the administrator.

And then, so you could look at all the different ACLs per feed by using the show ACL command line, and you can get the resource UID also by using a list feeds or just by browsing the Library as an administrator, you'll be able to figure out about all the different UID in the URL directly.

And if you'd like to open some feeds such as this one, from Nathan, if you'd like to open this feed to a specific user or for-- to a specific group then we have this add access property for the pcast command line that will allow you to add a specific access to a specific user for a specific resource. So for example, if I just copy/paste this here and execute this command line, then the user, Eric, will have access to this particular field automatically. Thank you.

So in summation, so what you learned from George's part of the presentation is that you need to plan ahead. There's a lot of questions that you need to ask yourself about deploying Podcast Producer before you even start setting up your first server. There's a lot of infrastructure. You need to determine what type of file system you're going to use, how big and how many Podcast you think you're going to be creating. How big of an Xgrid do you need.

Basically, you're going to have to be able to run a lot of tests to make sure that you have a general understanding of what you're going to be producing. And now with the Podcast Library, we've made it extremely easy for you to integrate with your existing web environment so that you can decide how you best want to show your content to your audience and to your end users.

Make sure that this is really customizable but you can create your own feeds and you can specify your own queries so that you can have the best feeds and the most intelligent feeds that fit your needs. And we have a very granular access control system so that you can decide who has access and make sure that only the right people can see the Podcast and your content.

So for related sessions, so most of these have actually already happened, and it's mostly if you're watching this in video, there are a lot of sessions this week. But what I really think is going to be a lot of fun is the next session that's going to be right here in this room. We're going to be talking about the technologies that empower podcast producers.

I really encourage you to stay for that one. Also if you have any questions, if you-- about the library or anything else we've shown you this week, we'll be down in the IT lab starting at noon and we'll be happy to answer any of your questions. There were a lot of-- there are already a lot of support resources out there for your deployments, so I'm going to leave this slide up and make sure you guys can get the different URLs for what you're interested in. And there are really a lot of resources out there already, and I really encourage you to take a look at the different K-based articles out there.