 So it's exciting to be the one standing between you and your lunch. Well, before we talk about the future, we should talk a little bit about the past, and I promise this won't be very long. But starting around 1994, people remember Netscape 1.0, Mosaic, before it. What's surprising about this is much of the chrome, much of the buttons around the outside content window are, you know, different icons, but the same buttons as they are today. You've got back, forward, reload, home, stop. You've got a proper number right, letting you know the page is loaded. But as changed over time, this is Netscape 2.0. It looks really similar, except the icons here, is what you can do inside the content window. Netscape 2.0 introduced, among other things, frames. Do, which is basically the workhorse of Web 2.0, animated gifs, which we've come to know and love, and JavaScript. So before Netscape 2.0, you did not have in-browser ability to script your web pages. Just static content sitting there. You wanted to do something, you had to do plugins, applets, do something else. And in this time, the state of the art of web was a little something like this. This is Yahoo Circa 1996. If you actually look at the HTML behind this page, these are maybe five tags. So you've got your unordered list. You've got, you know, a head, of course, the hyperlink, maybe a couple of paragraphs. I guess I lied, there's some fonts there. But there's no CSS. There's no JavaScript. There's nothing exciting. This is something a, you know, new studio agent can bang out in the afternoon after looking at a tutorial. So that's what we saw. That was the state of the art ten years ago. What's the state of the art today? Well, Firefox is, at this point, about 85 million users worldwide. It's about 2,000 community-contributed extensions. On the Friday, we're up to 41 languages at an additional four. About 16% worldwide market share. And I'll talk a lot more about this. And thousands of people that contribute in some way or another to the code. Either in localizations, QA, marketing, or in the code itself. This was a present from the friends in Redmond, Washington on the launch of Firefox 2. It was quite a tasty cake. We made sure the interns tried it first. We've seen the movies. It's a trap. Don't get the cake. But it was quite good. So let's talk a little bit about Firefox 2. Firefox 2 shipped in October of last year according to how you build inside the content window. Features that are relevant to how you build content for the web. Among them is JavaScript 1.7. And I'm going to take you through that in a lot of detail as we go. An improved performance of the Canvas tag. We'll also talk a little bit about Canvas. We introduced what the UT DOM store is. The first application that is one of the building blocks that's going to allow you to take your web applications off the web on your laptop and use them on an airplane. In my spell check, primary way of interacting, it's important to make sure that the browser doesn't make you look stupid by misspelling things that you type. And then as people use more and more websites, the tabs that are part of the Chrome in the top of the browser become a lot more like a workspace. Something that you'll have multiple of if you lose it on a shutdown or a crash is something that will ruin your day. We talk about individual features of Firefox 2. I want to talk a little bit about the web. Just to give you a sense of kind of uptake of Firefox, this is what the first 12 days of the Firefox 2 launch looks like. So that's about a little over 10 million downloads in 12 days. Two times, three times faster than the uptake we saw in Firefox 1.5. Just wondering what's different. Stuff changed. So it's just an astounding thing to watch as people swarm and download the browser. That works out to now have to caveat any time, any one quotes browser metrics anywhere. Take them all with a grain of salt. They're all in perfect measurements. This one just happens to have the prettiest pictures. So I'm going to show it to you. This is worldwide market share. This is a 15-mometer, which is a French-based company. You can see, you know, Europe is a very strong center in general for support. Asia is much weaker in general. U.S. is still around 13, 14%. If you break down Europe, if you've got regions that are well more than 30%, some of them just breaking 40% in adoptions, others in the 16-20% range. Why is this important? It's important because it means that in many places, one-sixth, one-third, one-fourth of the web is using Firefox. It means that if we introduce new features and add more support for advanced web standards, we're pushing the bar forward and hopefully forcing other people to come along with us and support the latest web standards out there to allow you to build your great web applications. How many people here are web developers of some form or the other? A bribe. Good. Okay. So enough with the marketing and on to the technical. JavaScript 1.7, how many people have ever played with any of the JavaScript 1.7 features? All right. Okay. It doesn't count if you're in the Mozilla community. So JavaScript 1.7, JavaScript 2 is going through the standardization process. It's also known as ECMAScript version 4. And they're looking to finish that work off by the middle part of this year. JavaScript 1.7 is something that's shipped in Firefox 2, so it's available today for you to use and play with. It includes a number of features, and I'll take you through them in great detail. The question is, how many Python programmers out here or at least a cursory understanding of Python? So a lot of the stuff you're going to see in JavaScript 1.7, a lot of the things that makes JavaScript 1.7 fun is heavily borrowed from Python. So iterators, generators, led expressions, array comprehensions, destructuring assignment. I promise I'll go through these in a little bit more detail than a bullet list. So let's talk about them. So iterators. Again, if you've done Python programming, you construct an iterator from a list of objects of some form, and then you get to walk through the iterator using .next to get the values out until eventually you get the end and you get an exception generated. Stop exception gets generated, then you can catch that exception and do what you want. Obviously, that's probably not normally how you would use an iterator. That's not the most useful code on the planet. What you're more likely to use, use them and the built-in try-catch that you get out of a for loop. So instead of initializing the variable, incrementing and checking the value in your classic for loop, you're doing what people are more used to these days, which is basically saying, you know, for foo and foos, do something useful with that variable within that for loop. Generators are a little more interesting. They allow you to yield control from within one of your statement blocks and return a value back. So in this for loop, I'm yielding control back and passing the value of I in my for loop. That generator will then return an iterator, which I can use together to do things like this, where I can use my function to generate new values on the fly and again, use stop iteration. So these are nothing new, nothing you couldn't do in some form or the other in an early version of JavaScript, but certainly make it a whole lot more fun. A lot less code, a lot less redundant issues. Blocks. So block is a different way to scope your variables. It's like a better bar. You declare let variables within different scopes, the function scopes in particular. So that value of that variable is locally scoped in there. It does not collide with any local scope. Let variables have basic default scope within for loop. So again, you can combine these structures together. You can use iterators. You can use let values to have effectively local variables within a for loop. So again, for your Python programmers, array comprehensions, to shove a bunch of values into an array of what I can just do it in line here. So what we're doing here in this case, we're generating an array of squares. So we're saying i times i for i to count of 10. Again, using iterators, first 10 squares. And then we can print them out. We can do odd squares. We can do creative things like creating an attack matrix where the diagonal's been removed. Again, not something you'd probably do on every but ten adult assignment, but looks neat on a slide. Alright, pushing assignment. Again, while I have swapping the A and B variables, instead of loading it into a temp, you can basically do it in line. Even more useful than that is being able to return multiple variables from a function. So you can, in this case, you know, assign sv0 to the output of whatever function this is that returns it. Works for objects as well. Works within for loops. So again, this is where you can, you know, write code to say things, to do slices and for loops and iterators together. For say, for foo, bar, and foo bars that use foo and bar within the body of my for loops. Again, not something you'd create in the program in a different way before this. It just makes it a whole lot more fun. A lot less code, much more compact. You can also do some crazy things. So Neil Mix said the yield statement had tried to build basically threats within JavaScript. You know, as you know right now, the JavaScript runtime that's built in the browsers is a single thread. So what you can do is use a technique called trampolining which is basically like cooperative multitasking. You can basically pass control back to your parent thread and build effectively a thread library. Now what's interesting about this is not that you actually want to do this in real life. What's interesting about it is by building on the basic features of generators within JavaScript, you can generate something like this and in this case 4k code versus the 90k code it used to take before to do this. So that's JS17. And I'm going to talk a little bit about JavaScript 2 towards the end. I think the other exciting thing, again, these are all things you can do today, is Canvas. Unfortunately we had some AV issues, so I can't show you the demos. How many people have seen the Walker demo in Canvas? Okay. For those of you who can't, it looks just like this. It looks like Doom, you know, circa 1994 maybe. But Wolfenstein 3 is probably closer. Pathways to Darkness for you Mac fans. A whole bunch of games. But, you know, it lets you run around a maze. It's textured. It's all running straight within the browser. You're not downloading a Java applet or anything like that. And it's using the Canvas tag. The Canvas tag is a tag started by Apple and then picked up by us in Opera and looked into the WhatWG working group in order to standardize. Allowed you to draw images within a data or other elements within your HTML page. So if you've ever done 2D programming of any kind, moved to Marring 2, Fiddles, copy images, all the basics are there. You can build really powerful things. It's not just for toy demos. If you've seen Yahoo! Pikes, so this launched two or three weeks ago, it's a way to kind of live mix up data from the web so I can grab one URL, grab from another, put them together, summarize and generate, for example, a new RSS feed. It's got this really killer editor which lets you drag around the boxes to adjust where the input of one workflow effectively goes into the output of another. And this is all done on top of Canvas. So, again, fire my browser, point it up there. I can drag the elements around. They don't have to load any plugins. Allows you to build what you'd expect on the desktop, which is a really rich web application. So that's what you can do today. So what are we going next? I'm going to talk about four different things in terms of where we're going next. First, in terms of JavaScript itself, talk a little bit about JS2, JavaScript 2. Talk about the basic building blocks required to take web applications offline. So this means what you can do to take your web application, disconnect from the net and still use it. Talk a little bit about micro formats and talk for about a second about what we're doing with web tooling. So, JavaScript 2. I think there's two very common answers to questions that Brendan and other folks are deeply involved in JavaScript 2 to get asked. The first one is, why the heck are you touching the JavaScript language? All the browsers can't seem to agree today on how to implement it. Why are we creating this whole new standard and this major rabbit of language? And I think if you look, as I take you through some of the goals of JavaScript 2, it really is about taking the web forward and taking us out of the blink tag and unoveraged lists from the early 90s and into these entire office suites and web applications on the web. And so what we're trying to do is, number one, fix the problems that people have been griping about for 10, 12 years using JavaScript and number two, really support programming the large. This means lots of people collaborating together to build web applications and doing so without a whole lot of shenanigans along the way. So taking you through a tour of some of the big parts of JavaScript 2. First is typing. So JavaScript as it is now is mostly, well, you know, untyped language. What we're adding to JavaScript 2 is the ability to do type annotations and we'll talk about this in a little bit in order to get better invariance at one time to make sure that you can program with contracts, to make sure you can write functions that expect certain values and it's checked by the system in order to allow you to build applications that are big and suitable for the web out of games, spaces, and packages and some of the features that I talked about in JavaScript 1.7 are already implemented in terms of destructuring assignment, iterators and iterators. I didn't talk about operator functions as part of JS 2 and some improvements to the basic objects. So I said the first question was why the heck are you doing JS 2 in the first place? The second question is oh my god, JS 2 is really big. Did you take on too much work? Why are you doing this big language route? And I think a couple of things happen. If you tease apart everything I'm about to talk about here, it really boils down to two or three major things. The first is the introduction of types into the JavaScript language and building a sound and formal type system. That's not something you want to do piece by piece. Something you have to do basically in one whole shot. The second is really to just fix up some of these problems that have plagued for a long time. And the third is to add a lot of the syntactic sugar, a lot of the niceties around iterator and generators that you build these web applications. So let me take you quickly through some of the basics of types. So types, first of all, again it's type annotation, which means it's optional typing. You can still program the same way you did JavaScript, which is not using types to your variables, but if you choose to, you can declare variables with types. You can write function signatures that request certain types on them. So in this case we're saying writing a function which takes an anchor string and a generic object. You can do multiple parameterized values passed into a function so you're not fixed to a single prototype. You can have basically a set of fixed variables plus whatever else and people can pass in different amounts of arguments and send that as an array. If you use Java generics or if you've used templates in C++ you can build parametric lists and parametric types in JavaScript as well. So you can construct a list of only type T or type foo, whatever it may be. You can also use structural types. So if you don't want to build classes you just want to build structs groups of objects together that are used in them. I think more interesting and exciting is the use of classes. So this is again going to look very familiar if you've done work in Java, if you've done work in Python, any of these other languages. You're going to see ways to encapsulate both data and functionality into structured objects called classes. Classes look a lot like classes do in Java for anybody. You can drive a class from another class by default it's sealed against mutation. It looks a little bit something like this. I extend another class. I have a set of function declarations and implementations there and I construct it just like I would do in any other language. Interfaces. Interfaces are like classes except there's implementation. The key difference very similar to Java again is that any class can only extend one of the class but can implement multiple interfaces. So with an interface you're trying to define a contract and not defining any implementation of how this actually works. So again you see something looks a little something like this. I declare an interface which is simply a set of effectively method signatures. I then have a class or multiple classes in many cases which would implement that interface. There are several types as well so you can declare types as just either a function or a series of data members with no implementation. So that's the basics of classes. I went over that really quickly but if you've used any of the modern programming languages that use object orientation allow you to coxulate your functionality, your data into one object that's effectively what we're doing here. Again making it familiar for people, making it fun making it easy to build large systems within JavaScript that run on the web version of additional software. The other key part of this is namespaces. So if you build classes you're going to want to make sure that you can have certain parts of those classes that are exposed to other classes and certain parts that are private parts of the implementation. So in this case we can declare public, private and internal implementations and this is on a class basis. And the namespaces are used fairly generically. They can use both the namespace entire package systems. So in this case what I'm saying in class C function is in the improved namespace and I can basically call the namespace directly by qualifying it while I'm calling it. Or I can import an entire namespace and then I can use it shorthand without having to fully qualify the namespace as I'm going. This can be used to build packages. So if I want to create, for example, my org bank fin package and implement a series of things in there then I have different ways just like in other languages to import an entire package or select the way import individual classes. Again, this is super important mostly for when you're building huge systems. I'm going to take data from different parts of the web, different people implementing it and you don't want to pollute the global namespace. You don't want to have flashes of classes and variables. It allows you to constantly what you're doing and make sure that you're safe from other implementation. Decimals and you only bring this up because this is one of the most important things that I'm going to do is look at the size of the OZILA which is why the heck is 7.49 minus 35.99 equal to that number. So there's a new decimal type that will be implemented. There's a long number of other small features in JavaScript that I'm not going to go over now that improve a lot of these sorts of issues. Issues that people have to bang their heads on over and over again and fix and work around in the browser. This is coming real soon now. As I said, the spec is being worked on over this year and what's also different about this version of JavaScript is there's a reference implementation being developed in parallel in ML. So it means it's not just a weekie or word doc. We'll actually have a working running reference implementation that all the browser vendors can compare their implementations against to make sure we're getting a better shot at equal behavior across all the different platforms. The other exciting announcement that you may have seen is that Adobe has decided to donate just in time compiler for action script slash JavaScript called that we're now calling the Tamron project so they now system the fall. That will be integrated into a future version of Firefox. So it's going to allow extremely high performance JavaScript on the web. Just in time compiler is obviously a way to get virtual machines to perform extremely well. The other thing to note is that this is probably the last big bang we're ever going to do of JS in a long time. Realize it's not like all browsers are going to adopt this overnight it's not like all websites are going to do it it's going to be a slow adoption. But once we get there we're going to have technology sitting on your desktop on 95% of people's desktop that will allow you to build these big rich applications without installing any additional software. So that's JS. JS2. Yes. Yes. Don't read that word it's built wrong. Thank you Axel. JS2 proposal relate to previous JS2 proposal that's been done five years ago. Kind of doesn't. Yeah, it's kind of a restart. All right. Just where are the other browser implementations in terms of supporting JS2? Yeah, it's a good question. There are other browser members participating. Agmyscript is an open standards group so there are many other people participating in the standards. Firefox is probably furthest ahead. JavaScript 1.7 is kind of a halfway point to JS2. No one else currently has 1.7 implemented. We probably won't have JS2 implemented until sometime 2008. It will probably be the first since we're heavily involved in there. So you would expect this is something that's coming over the next couple of years. Not something you're going to see this year in most major browsers. I can't speak for anyone. I'd hope they implement but I never know. Let's talk about offline. Does everyone get the basic concept of what we mean? So it means I'm reading Gmail, messages I've already downloaded. Just like any desktop application that allows you to look at what's on your desktop without having to connect. So what we're doing is building the basic building logs that any web application can use to take themselves offline. So offline really composes three main parts. First thing I've got to do is I've got to be able to store data offline. So if I'm building an offline email client I have to be able to take my messages, my email messages and headers and shuffle them somewhere on the disk and be able to access them when I'm not connected to the net. So that's implemented via 1WG which is the what's working groups and formal standards body, DOM storage and that's already partially implemented in Firebox 2. The second thing I need to do is if I can store my data offline I need to be able to store code and other resources. So I've got JavaScript which is going to run in the browser on my offline application. I've got CSS files, I've got images, I've got other things. I need to make sure I can get to that stuff without having to download it over the net because I don't have a net connection. And so that's what we've had offline caps which I'll talk a little bit about. And then the last thing obviously is your app needs to know whether it's online or offline so that it can behave properly. Re-sync when it comes back online, it can make sure to not make network requests when it's offline. And so we've added online and offline events. So you can reach these. DOM session storage. DOM session storage, you can think of it basically as a big hash table on the local disk that is associated with your session. So it goes away if the browser is explicitly closed it stays around if it crashes or something else happens. And you can use it to basically fetch any string value you want. So in this case I'm just shuffling the value of the checkbox on my web page into my DOM session storage under a variable name and insurance. Then I can go back and I can query the value of that variable later on within my session. Even more interesting probably is global storage. So it's the same thing. It's a hash table that I can use to store values except that it's a per domain value and it's persistent. So I can store values, shut down my browser, restart my computer, start my browser back up, pull the value back out without ever having to go back to the net. And so this is one of the basic building blocks of building these web-based applications. Security is obviously an important issue. You want sites to be able to securely store the data there. So domains can access some domains and vice versa. So you can build a series of cured sites that can share data across them that they want. But we don't allow across domains. So obviously www.2 example can't hit www.examples site. All of this is specified in the whatwg working groups specifications. Much of it is implemented in box two. Again, we hope other browsers will continue to implement and we'll finish the implementation of bar box three. The last part of this whole puzzle is the offline cache. And that's as complicated as it gets. It's a link realm. I basically tag my resource and I'm saying json.js and 2d.html. I want you to pin them in the cache so that when I go offline, I can make sure I can access those resources and make sure my json.js is there. My json.js whatever it may be. By simply adding these additional metadata onto your web page, we will make sure to pin it into the cache and make sure it's available for you. And this works in the latest nightly builds of bar box. Where you don't go yet, it will probably go away. What happens if every website on the site says hey, I'd like my website to load faster next time you come back. I'm going to use full resources to help my cache even though I'm out there in the application. You'll fill up your cache and we don't know it will happen. Yeah, it's bad. That'll be bad. Don't visit those sites. This is the future, so we don't know it all yet. I knew that I'd be playing the stock market and not here talking to you. Not too good, but there's lots of things that work out. This is happening in real time in terms of doing it. We just started getting this going. The last thing is online and offline events. This is really simple. It's basically how does your code, how does your application know whether it's on the net or not. And it starts with a navigator on online property, which I think actually already existed. If so, I should probably shuffle my data up to the server if I'm not online. Maybe I should shuffle with the local storage and deal with it there. And deeply as important rather than checking in a loop what's going on there's a new series of events going online and going offline. Offline and online really is what they are. You can register event handlers for to be notified when your app goes offline. So in other words, if I want to wait, get notified when I go online and automatically sync my data back up to the server, I can do that quite easily by registering an event handler just like you would do anywhere else. A little preview of the future there. Alright, so as I said, unfortunately I can't show you the demo on the other machine here, but it turns out to be with these three building blocks relatively trivial to build applications. We've got a couple of sample applications. One is just a to-do list that allows me to store a bunch of data locally. And the other is, if you've heard of a company in an open source project called Simra, it's basically a server that has an open source edition. It's kind of like a Microsoft Exchange competitor but all open source. Someone from the Missile Project spent about five to six days, took the source code and made it fully offline compatible. So you can compose emails offline, drag them around folders when you get back onto the server, or you can go into the send box and send them out. So this is not something that requires people to completely re-arrow and detect web applications to download new stuff to program in a different language. It's literally just take your application make sure your resources are organized in ways that we can pin to the cache, make sure you know when you're online and offline, and store data offline. So as this gets implemented we're going to see probably a lot more applications do this very, very quickly. And there's all sorts of easy use cases. Read email, RSS feeds, even Google Docs and spreadsheets, being able to take a doc offline, read it on the plane without having to explicitly download it beforehand. So that's offline part of the future of the web. Adgress away in my address book so I can do something useful a little later. I may want to add an event that's got a date on it in my calendar or something I'm going to go to. And today what you do is you kind of green screen cut and paste, where I kind of cut and paste, grab the text, drop it somewhere else, maybe re-format it and hope that it works. So the basics of micro formats are, hey if we could code a little bit more data in there to let you know that this is an address or this is a dating time or this is a phone number, you can start to build clients that do intelligent things with that information. So we've already built a micro capillary, built an extension called Operator, which is available to download now in Firebox. And what it basically does is it looks for content on your web page and tries to do useful things with it. So in this case, if you go to Yahoo Local you'll look for an address for pizza delivery or restaurant. Instead of again, manually cutting and pasting that, you'll see in the upper left that it's found this information and you can take, just contact it and export it directly into your contact store of your choice, your H-card, B-card system of choice. So if you're on a Mac, it'll take a contaminated the address book and now you've got the address and phone number, jing column and do something useful. And so the basics of microformats that we're looking at to try and do future versions of Firebox and hopefully on the web is to build the basic building blocks so it makes it really easy for web authors for extension authors and other people to expand this set of microformats. It's not going to be a set of things that we ship in the browser or rather ways to discover that you've got content for five people that, hey, there's something on this page you can do, you can act with. This is a tool bar as a prototype implementation and it's certainly not done. You can imagine hovering over the address with a little sticky pop-up or whatever it may be. Or we're going to build the basic building blocks to make it trivial for someone to say, here's a new content type, here's a quick parser for it, here's what you do with the data and plug that into the browser. So that's what we're doing with microformats. And the last thing, there's another demo unfortunately some other time I'll show you the last thing, everyone here who's done development on the web is probably seeing Firebug. Firebug is pretty awesome. Firebug is an extension for Firebox. It's basically everything you've always wanted in a JavaScript slash CSS slash HTML debugger or more. And I think what's important about this is when you think about what we're trying to do with the future of the web, we're trying to make it possible and we're trying to make it fun. Because for a lot of us programming isn't just like a job, something we do, it's something that's fun and interesting to us. And so aesthetics matter. You know, banging my head against the wall is a problem that I know there's a better way to deal isn't something I'm going to keep doing after a while. And Firebug is one of these things that makes development fun. You can twiddle the CSS, you can get timings to figure out exactly which part of your script is running slow. You can watch HTTP requests go by and figure out which things are hitting the server when and where. Up to par with what you've seen in other applications to make sure that it's not just a text editor and the JavaScript console or the only weapons you have of choice when you're building web applications. But making sure you have a totally rich tool set that builds these things. So again, what does all of this stuff mean? So you're going to ram a lot about iterators and generators. All this got to do with JS. But at the end of the day, what we're trying to do is make it so big teams of people, collaborators from all over the world can get together and build the next generation of web applications. Things that we couldn't even think of today on the web. We want to make it fun. We want to make it aesthetically pleasing. We want you to sit down, develop something on the web and say, oh, that's cool. Look, I can just do this kind of thing, this iterator thing instead of writing all of this code. Because then you'll do more of it. That's what really motivates people. We're trying to make the web indistinguishable from the desktop. What I mean by that is there isn't anything you should be able to do on a desktop application that you shouldn't also be able to do on a web application. If you think about what the few things are that are that case right now, we're going to take care of them this year. So the first thing is offline. Again, I can't sync my data offline. We're going to fix that. We're going to do it in a standard-applied way so that people can come along and make it so that you can take your web applications with you on the road. Graphics is another big area. You're seeing a lot of eye candy with things like better SVG implementations and all the browsers. And the Canvas tag that will allow you to, again, do these rich graphics that aren't just toys, that allow you to build graph editors and other projects. So you're going to see those kind of things getting done. And then the last pillar is performance. So by increasing the performance of the JavaScript engine and the scalability of the JavaScript engine through a just-in-time compiler in the future, you're going to be able to build all of these things in 10 days. And again, much of this is here now. Much of this you can play with, either in existing versions of Firefox or future versions. Much of it is specified, either in the echo working group or the 1wg documents, so that everyone can test their limitations and make sure it works. So that's the future of the web. And I know it because aliens told me about it. Stunned you into silence. Yeah, I'm not I don't know the answer to that. It's a short answer. So probably will not. The caching system doesn't store anything persistently now. As you know, we never capture this in SSL transactions. We do capture RAM in certain cases. So, likely those two things won't be compatible. You may have to serve up some of the content on RHDPA. Some of the GSD stuff. Will it change the way extension developers interact with xd.com or ford? Is there something about xd.com that's more specific in there? It's a little bit laborious as far as photoregret and free look of things like that. And I saw the interface stuff and it kind of spelled a little bit like some of the main xd.com as far as explosives and browser functionality. Instead of exposing it in JavaScript, why needs a set of xd.com? Yeah. So the question was for Firefox extension developers will JS2 help me not have to deal with xd.com? And the short answer is JS2 probably won't. But over time because we're making JavaScript an easier language to build components of the browser, because the performance of the engine is increasing, basically almost any code we touch in the browser these days for writing a JavaScript unless there's a reason not to. So the main rendering path will probably never be in JavaScript, but an easy example is the password manager, right? There's nothing really performance intensive about password manager. It's a whole lot easier to write and work with than JS. And so you're going to see this as we evolve and touch different parts of the system. A lot of stuff implemented in JS and exposed through JS interface is hopefully rather than better. That's the other thing we're doing is trying to build better interfaces so if you go to developer.mysl.org it's all there. It's kind of the first start of what are all the common things extensions do and how can we put that into a nice little library that everyone can do that you know, do common operations that's part of ours. I think we'll probably try to understand just a little bit how it should be implemented from that and that part of the meaning. So I'm going to see why then. So that is what we're going to do. Is that going to be official or is it going to be like JS where you're talking about the process of the application and you're talking about the process of the application. So I think that's the the last step. I'm sorry. Or I don't know. I'm sorry. The question was will we have an ideal so we're confused as to what the answer is. Or it's not very helpful. Sure. Mike, you talked about taking all the desktop applications to the web. When are we going to see a web-based video editing? It's already there. The question was about web video editing. So it's probably not as good as Final Cut, but we'll see. I think it's going to stress Canvas a little bit, so we'll get there. But we'll get there. You have a back. How about if you're in an offline cache, how do you make sure that users notify that sites are using offline cache and for example, when using public computers? Yeah, that's a really good. So the question was offline caching and security. How do you notify users of the doing that, and especially if they're, for example, on a public shared web terminal. You're not going to like my answer, which is another one of these, we're still kind of figuring it out. There's a couple of parts to security with offline cache. Let's let them know that the data is there. Two is, in Firebox 2 it's all plugged into the clear private data function. So there's a feature in Firebox to basically remove all my cookies and history and anything that might be sensitive and personally identifiable. So the offline cache is already plugged into that. So that will also be cleared if you clear private data. So that's the easiest one, which is just, if you're ever using a computer that you don't want people to see what you're doing on it, just clear your data and you're gone. In terms of letting people manage the storage and see what's there, which sites you're using it, that we haven't actually gone down part of the path and understand what the UI is going to look like there yet. You've already got one, so I'm going to give it to someone else. Yes. Thanks. You want to answer the question? So the question was video on Codex and what's your future of that? It's something we're really interested in. I don't think we're going to get rid of lots of different Codex in the future, but there hasn't been a lot of questions about, I'm pretty sure video already is a big part of the web as is audio. Whether it belongs in the browser with some kind of Plugable Codex system, so that at least the basic frame of the player is there, or whether it continues to belong in plugins the way it is today with Flash and QuickTime and WMP. I don't really know yet. I think that the one thing we are really interested in is possibly. I think the thing that's most interesting to me about video is how to make video jump outside of the little box and actually interface with the rest of the web. And so if performance weren't the issue, and you could have video within a canvas tag, for example, be able to style, rotate, have it interact with other pieces of the content, I think that's where the future of the web is with video. How that's actually implemented we're still kind of figuring that out. The question in the back. It was something like a security manager in Java. In Java, you just stick a declaration to the top of the page and then that browser and will it actually build to the JavaScript with what you're doing and what you don't want to do. Yeah, I'm sorry, the question was can you implement a security manager in JavaScript? What is the to do permissions for? What is the thing you're trying to do? We're making links to external websites and things like that. Yeah, the answer is yeah, we would like some ways to declaratively it's been a common problem on the web these days for people who have to do content filtering. So you have user generated content you upload it to the page you have a small bug in your content filter and someone's able to get some code through there and then way more you've got a cross-site scripting attack on that site because I can upload code and run it in the context of your session and steal your cookies and then steal your blog and do whatever I can do with that. So we are looking heavily at ways to add some declarative parts to JavaScript. Some really basic ones would be basically like no JS after this within this block or no JS after this tag is loaded so you can scan things out. Lots of different ways to try and do it so that you as a website author don't have to deal with it. Especially as the specs for things evolve, you don't have to keep up with what all the latest tags are or that sort of thing. So it's another one of those yeah, it's something we will be doing soon, hopefully. Is there a proposal for that? at www.juve.net slash security slash content pipeline restrictions which I'm hoping to get to in the next couple of months. Cool, probably one more question and then we're time to eat. No?