 Okay, we have five minutes passed, so I think let's get started. Quick question, how many of you attended the last talk that I gave on JavaScript engines and hated the template? Sorry, you will have to live with it, I mean, it's about JS, Foo and had that Samurai ninja kind of a feel. So I thought, let me just copy that and copy that for this talk also. So yes, this is a talk on index DB. Let me ask the question again, because we have a lot more people. How many of you have used index DB? Heard about index DB, good, that's a good number. So I don't think I have to go through the basics. You must have seen that this is an intermediate level talk, so I will just be doing a refresher on basics. So how many of you here have seen Star Wars? Star Wars, one, two, three, four, five, oh, that's a good number, okay. You know, when I tried to design a theme for this, though I knew it had to be some ninja Samurai kind of a thing, I could not get Star Wars out of my mind. So I said, fine, I just do Star Wars. So I also know that I'm the guy who's keeping you from lunch, so bear with me, I'll try to make this topic as interesting as possible. Shout me down if you think I'm getting boring at some time. So yeah, apart from knowing me as the guy keeping you from lunch, my name is Parashuram. I'm a senior program manager at a company that also developed browsers, and I've worked on the IndexedDB specification a little bit. So here goes the story. Long time ago, in a galaxy far, far away, there was IndexedDB. You know, funny that it's actually a galaxy far, far away because a lot of people here are not able to use IndexedDB, right? So that's still a galaxy far away, and I also tried putting that Star Wars kind of text. You don't have to read this. I put this text up to tell you the kind of applications that you would use IndexedDB for. IndexedDB is effectively a database in your browser. All of you till now have been having databases on the server where you store stuff. IndexedDB is just bringing all the data on your browser so that your apps can be one intermittently connected like mail or calendar, or like last talk where Pratik gave where his bug databases can be on the server, on the client rather. Secondly, completely offline applications like, say, word processors and things like that, which you don't really need to connect to the server. And finally, you can also use IndexedDB to save bandwidth. So rather than keeping the user preferences on your server for privacy concerns and all, you can just leave it on their browser. That's IndexedDB. So quick IndexedDB refresher. What is this? What is this? Have you guys worked with it, used it, louder? It's a browser. Okay. It's a browser wireframe. Let me put it that way. Because I know a lot of people would say it doesn't look like a browser, but it's a browser wireframe. So on a browser wireframe, you would load a page in that white area, right? That's up. That's the domain of the web page. So what does IndexedDB do is, as I told you, it's a database inside your browser. It's like I'm trying to pictorically represent the term database inside the browser, but that's what it is. And what can be there inside a database? There can be tables, right? How many of you here have actually used databases? Oh, good. How many of you here are DBAs, database administrators? One, two, three, four. You can count them. How many of you here are front-end developers? And the rest are back-end developers? Okay. You know, yeah, you do both, too. That's true. Or some do neither. That's the other part. So the thing is, I've actually seen a lot of front-end developers or developers in the world looking at DBAs like as if they are those guardians of data with like those titanic shields and those spears and all sitting and guarding data, right? So here's your time developers to play with databases because it's right there in your browser. So as I said, database has tables, but in case of IndexedDB, it's not a relational database, like most of you know. So IndexedDB does not have tables. It has a concept called object stores. And object store saves objects. And object is basically a key and a value. So things like 1 core, X core. So it's a JavaScript object, basically. So object store is this. And on the object store, you can have indexes. What is the use of an index in a traditional database? Saves time. What is the use of an index in indexed database? What is it? It's the same. They didn't want to play around with the terms, so it's pretty much the same. No, this is not memcache. This is actually... So to put it plainly, it's effectively a database inside your browser. It's a real database. So in Chrome, it's level DB. It was SQLite. In Firefox, it's SQLite. In Internet Explorer, it's ESC. So it's actually a database, a living, breathing database. Local storage, you can't do things like iteration. So I'll come to that. But basically, this is a real database. Local storage is a fake database. It tries to... Yeah, let me get to that. Let me get to that. So effectively, you are a victim of the local storage propaganda. People have fooled you into believing that local storage is a real database. No, it's not. Yes, I will also come to that. So the content of my talk is... This is going to be just a preliminary. I'm just going to talk about this. But I'd be trying to fit on the fact of why index DB came into existence, what existed before it. I'll probably be trying to tell you a story. So let me just quickly get through that Star Wars kind of that initial yellow text that you see, right? Let's just get past it and let's see some action. So you have indexes. You also have this concept of cursors. A cursor is basically an iterator. And you can iterate on cursors also. On a single web page, you can have multiple databases. And this is just some more Star Wars-like text, where you have the concept of transactions like you have in regular databases. And the database APIs are in two flavors. It can be asynchronous or synchronous. This is all you need to know about index DB for this talk. That was the question. So, yep, here starts the story. In the days of the good old republic, people actually used to use cookies for storage. You know, the problem with cookies is you can't iterate over it. You can't query over it. You literally can't do anything that you can do with a real database. And yes, you had the cookie monster where you had only so much space that you can use. And there comes your question about local storage. Local storage is not iteratable, first thing. Secondly, it's not synchronous. It's synchronous. It's not asynchronous. So the moment you start storing tons of data inside your database, it's going to take up time, right? It's not true, but is the object enough? You will not be able to iterate over it. You will not be able to select it based on indexes. You know, so for example, you have an employee database and you want to start... You basically want to have an index on names because you want to make all of them stand in a line alphabetically. Probably on a fire drill or probably on a fire... Yeah, it's more than a key value pair. It's a real database. So database is not about just putting stuff in. It's about being able to do a little more than that. Well, that's actually changing with the structured cloning algorithm that people are going to implement for... Makes sense. So yes. In fact, even index DB has size constraints. So that's dependent on the browser. The size constraint isn't as much. That's the point. So yes, cookies and cookie monsters. So that was the days of the old republic and then came some Jedi to restore balance in the force. You basically had Google Gears and that's the story about WebSQL database. So Google Gears was effectively a summer of code project in Google and amongst other things like web workers and stuff, they also had databases. So Google Gears is like this collection of things that web browsers should just have, but they don't. Things like background threading or things like SQL databases. Stuff like that. So that's... One of the earliest indications of databases was the database module of the Google Gears first released in 2007. And effectively, they started using SQLite kind of structure. The reason, it was a summer of code. People wanted to get something quick and running. What they did was Google was... Chrome was anyway using SQLite for storing bookmarks and stuff. They just exposed the API outside. And that's why Google Gears was the WebSQL database module. What people did was they thought, okay, Google Gears is specific to Google. They started calling it Gears when it was open source. And then they tried to make it a standard and called it the Web... They initially called it the Web database API which was then renamed to the WebSQL database. So it is a dialect of SQLite 3. Unfortunately, SQLite 3 is not a standard. And a lot of browser vendors do not accept the fact that a standard should be based on a product. It should be the other way around. So the Web database API as of today is frozen. By the way, those two references are actually chats. I was not able to find... So I had this in my chat history. I was not able to find email references. So you have W3C committee chats where you have these IRC chats, right? It's one of those. I should have probably read the spec rather than just reading the mailing list. Yeah. So that was the days of the old Republic when a hero came back and saved the day. But then a hero was born. That was WebSimpleDB. So there was this gentleman called Nikunj Mehta from Oracle. He'd done a lot of work with BerkeleyDB. How many of you have heard of BerkeleyDB? Louder, louder. Okay, funny. IndexedDB is based on BerkeleyDB. That does not mean or does not imply that IndexedDB is sucky. However, the basic idea is that it's an ISAM-based storage. No queries. It just put values in, get it out, have indexes on them, and that's pretty much it. Apart from that, this is where the concepts of things like entity stores or indexes or cursors came in. This is the first frozen spec. So I think the spec has four versions that are out for review. So these guys have this spec list where they keep committing stuff. There are four marked or tagged specification versions. The first one actually talks about things like entity stores, cursors and all. You understand what an entity store and a cursor is, right? An object store, a cursor and index. So that's when they started talking about it. Though they wanted to make it asynchronous, most of these APIs were actually synchronous. So if you want to open a database, the code for that was synchronous. If you wanted to open an object store or get an object store, you used to do dot get entity store of entity store name. And that was synchronous. So I remember there was this gentleman called Jonas Sikking from Mozilla who actually wrote up an email thread to Pablo Castro from Microsoft saying that synchronous calls are actually slow because synchronous calls will effectively block your UI thread, right? Why do we do Ajax asynchronously? Blocking, right? Same story here. So that email thread spawned, there was a good discussion about it and they tried to move a lot of APIs into the asynchronous version. However, having said that, the async and the sync model were thought of even then. So even in the first draft of the spec, they said that there was a synchronous model in the WebWorker modules. How many of you have heard of WebWorkers? What is a WebWorker? You spawn a background. It's not technically a thread. Browser vendors may actually fight over it, but it's not a thread. It's kind of hard to define what it is because it's an execution context. That's a good way to put it. Fair enough. It's a way to do background processing. So synchronous was supposed to be there in the background, while asynchronous was in the foreground. The interesting thing is it was in the first spec that they spoke about things like sequences and queues. And they even spoke about things like entity joins, where you can join to indexes. So in a database world, what is a join? Louder, louder. Check out the commonality. It's a way of querying stuff. In fact, in the first spec, they had spoken about things like entities, joins, sequences and queues. Sequence is definitely a sequence of all the values. Queue is put, queue is the same queue, is the regular definition of queue, where you put in first and then the guy who's in first comes out first. They had all that in the indexdb first specification. And then in the indexdb spec group, people noticed that the force was strong with indexdb. And interestingly, it was actually implemented by a lot of folks. I have said I tend there, but you would notice that I8 had a prototype implementation of indexdb. The best thing was, rather than doing half hazard kind of asynchronous calls, these guys started using requests API. So a request is basically, just like while calling Ajax, you do a new XML HTTP request and then dot on sexes. Similarly, you create an object called a request. And on the request, you have success and a failure handle defined. So the request API started coming up then and the asynchronous API was made a lot more concrete. Very basic operations like even opening, so opening the database is still synchronous, but anything after that became truly asynchronous. And importantly, there was a lot of confusion about what kind of objects can you store. Can you say store a window object or can you say store a window dot object? There were questions about that. The second and the third version clarified saying they referred to this thing, this other specification called a structured cloning algorithm. The structured cloning algorithm is a simple algorithm that tells you how one JavaScript object is copied, is exactly cloned structurally into another JavaScript object. Yes, it will have to skip function because function will be out of context, right? Prototype as in? I'm actually not sure about that. It could copy the dot prototype property because the dot prototype is a strong reference, right? Things like DOM window, things that cannot be reproduced on the other side. I haven't read the full structure cloning SCI spec, but the basic idea being if you're able to copy it, the copy should have the exact same structure as the previous one. It shouldn't have any properties missing or it shouldn't have any extra properties and all. That's the basic idea. This is actually interesting because when you clone a JavaScript object and save it into a database, some other day you're going to retrieve it out of context, right? You're not going to have the same JavaScript context. That's exactly why you need SCI. Let's actually play around with index db a little bit. Actually, let me just go to the playing around later. Let me show you the latest version where it is actually doing a lot of interesting things. A young hero shows promise. Microsoft and Mozilla recognize this promise and they're blessed index db spec. In fact, Microsoft even went one step ahead and said that it will not implement the WebSQL database spec. I've actually seen Chrome doing both, but looks like they have retired gears. I do not know about OPERA. OPERA will throw out WebSQL and implement index db. OPERA is also going to do index db. Big browser vendors have accepted index db. This is where a real concept of a request. In the previous one, what you saw was, you would do it on success blah. But this is when a request object was defined. They said that there's a meta object called a db request and all operations open a database table or get data, all of them should return a db request. There's actually a pun with the title and the request here because these requests are very similar to JavaScript promises. Anyone heard about JavaScript promises? How many of you have used JavaScript promises? Not many. A JavaScript promise is effectively a cooler way of doing, or in fact a better way of doing asynchronous programming. If you view jQuery, the latest versions of jQuery, jQuery have promises. They're called deferreds, right? Deferreds. Await is a part, so that's a part of ECMAScript 5 where you have yield an await. The await is exactly, or is very similar to the C-sharp await. This was also the first time when the authors thought or spoke about security. For all you know, you're storing user data in the browser. What are you going to do about security? The idea about security is only the user who, the way it is implemented in Windows is index db is stored in the location of your user name. So any other user cannot access that. However, they also went a step ahead and said that if you're sharing browser sessions with other users who do not have a different user name, they will be able to read your data. That is a well thought out choice because there's no point in trying to encrypt and all. That's a whole new ballgame, right? So they said no to encryption. They said they will defer the access management to the operating system. They also wrote a section about privacy. This was written after this very interesting Cookie Monster attack where I actually forgot the name of that experiment where you go to a web page, they tell you to delete your cookies and yet they persist your private data in other forms like flash cookies or index db. EverCookie. It was called EverCookie. So the privacy section actually came in after EverCookie. And unfortunately the ideas of joins, sequences and queues are missing. That's kind of funny because now you're left with a local storage kind of a thing, right? And the gentleman here who said that how is local storage different from this? Well, he can now beat his chest and say, yeah, I was not wrong. There's nothing different. Well, yeah, you can just iterate, nothing else. You still don't have sequences, queues and all. It probably will come in later. They will definitely not be compatible with this because this is no sequel. So by now you would have guessed that this doesn't have any sequel, right? Let me show you how the code looks like and maybe that should explain a little bit. Looks like I do not have internet, so it may be harder. Anyway, I can show you here. So for an example, can you read this? You can't, right? Do you want me to increase the font size? No, so this is how index db, typically this is a classic index db example. So what you do is you do things like window. You do... let me not overdraw. So you have a request object, and to the request object you do a window.indexdb.open. So remember I told you that on the db request object, you define the onSuccess and onFailure handles. This is how it is done. So once this is opened, once this database is opened, you will be able to see the onSuccess will be called. And what happens in the onSuccess is this. Which one? No, in fact, even the open call is the same. It was simple as earlier. All calls now have been made as simple. So yeah, that's funny. When you open it, if it does not exist, it automatically gets created. Yes, let me actually show you that also. So I thought because most of you said you have worked with index db, I thought I didn't have to walk you through index db code, but let me do it anyway. So the other thing is I told you that there are transactions, right? So this is how you create a transaction and you can bind a table or an object... So whenever I say object store, mentally replace it with a table. So you can bind a table to a transaction and then you can have an add data request. This is how you add data to index db object. This is exactly how it looks like. Okay. Which one? Yeah, it's a... It follows the same cross-domain origin policy. Yeah. Just like you would share cookies, you can share this. That's a trick answer. The answer is you'll have to go to the server and come back. There's no other way out. You can share it yourself because... So effectively, what you could do is you can do a CORS kind of a thing where you can have an iframe, different messages, past messages between these two. Don't really have to go to the server at all there. But the guy who's... Both the guys who are interested in sharing should know that they're sharing. Yes. The question is there is no easy way to query objects. Any other questions about index db API itself? There's one question here about... Will it not? As far as a couple of browsers that I have seen, it runs in a separate process. So it's an embedded db, effectively. It's a tiny, really... It's SQLite, it's level db. Both of them are tiny databases, right? No, it actually persists it to 5. That optimization is deferred to the db implementation itself. It's what SQLite does. It's what level db does. So it's dependent on those guys, and I think those guys know the best, right? Because if it's a tablet, for example, it will be on tablet, and this may be different, right? So... You can't flush. You can't flush. That's the basic... If that's the question, you can't flush, you can't close a transaction. There's a 5mb... 5mb storage size, but not memory. Not memory. You can't fix it. It's in the same... So today there's no direct API, but just like geo-location asks you, do you want to share your location? How to do it and where to do it? So that's what's... In fact, there was a very big thread about people who, in fact, even I wrote in one small tiny para in that thread, where they were discussing who should be the guy who should ask for more permission. Should it be deferred to the browser? Should index db have an API for doing it? Because index db, API itself can access it, right? And the other thing is, what do you define storage as? Will storage mean space of the object store plus space of index, or space of only object store, so that's all hard to define. It's not defined yet. Let's write to the W3C committee on index db, and I'm sure they'll... So, okay, the guys in... point of contact are... Jonah Sikking is taking care of it from Firefox. Ben Turner is also from Firefox. Jeremy Oslo is doing it from Chrome. You can actually join the Chromium HTML5 group. In fact, even yesterday there was a mail thread about one level db issue that they had and they were actually actively discussing it. So you could write to them. No, so the level db, these guys may have it, right? So there's no API... There's no index db API that says, give me more storage. I'm sure it will come though, just like the location guys have done it, geolog... It cannot be shared by different browsers. It should not be shared by different browsers, because just like your cookies, it should... The sharing idea is just like cookies. It should not be shared. Firstly, because those Chrome hats equalize, they are completely two different databases. So in the earlier days, and Chrome also was equalized, you could just copy the database, put it here, and use it. Funny part is, the way these data is actually persisted, because if you notice, SQLite is a relational database. This is an object store. So the way it is mapped is also different in different browsers. That's why you cannot store it. Yes, yes, that's pretty much about what level db does, right? So all that is deferred to the actual database. This is just the database API. Any other questions before I can move on? Okay. The question is, can a database created in one domain be accessed by a database, or can it be accessed by another domain? What should the answer to it be? Why should it be no? Cross-domain issues, security issues. So there you have your answer. Same cross-domain policies. No, it's the same document or domain story. Effectively, just like Ajax, follows the same cross-domain origin policies. That is deferred to the database implementation. The database may or may not be stored in an encrypted format. You, however, could use not-so-enough JavaScript encryption routines. Encryption in JavaScript is a bad idea because the match dot random is not really random. So technically it is not. That's why I said, in the previous things if you notice, I said that encryption is deferred back to the operating system. So access management is deferred to the operating system. In case Firefox uses, extensions, if they are able to access the indexed GP API, yes, they will be. I would recommend not using direct SQLite calls because the format may change. You may as well use the page context. So how many of you have written Firefox extensions? Good. Jetpack or the XPA? The older ones. Oh, God. Okay. You guys are great. So you have the page mod modules, right? You could use that in the extensions to access the database. Through the web context. You can technically read and write files, but if you're doing that, I'd consider you my hero. Yes, in that case, local storage would be good enough. However, you can't iterate. You can't index. So effectively, the issue is you'll either get all the keys or you'll get none. Imagine you have 100 records. You just need alphabets. So you are a company CEO and for one fine day you decided to fire everyone between K and S. You wouldn't do that. You can't do that, right? So it's a sanity check. True. So local storage is good for smaller applications, but not necessarily. That's a browser-specific local storage and versus session storage, for example. So that is today. There is no guarantee in the local storage specification that says things should be in memory. In memory is because it's going to be fast. These browser vendors have done all kinds of things to make it fast. Nothing prevents you from storing it to the disk. Nothing prevents the browser vendors from changing the implementation as my pun. Hold your thought. So come over to the dark side. Now we have Anakin, I mean, index DB to the level where he has matured. He knows all the Jedi arts. But then shouldn't he go to the dark side? I think he should. So the cookies is not a pun, by the way. So this is where he encounters the Sith Lord. The Sith Lord says no sequel. Now guess it's not sequel, right? Well, really? No, it's not sequel. I'm serious. It's definitely not sequel. Okay, then what should I do for querying? Who has that question? Here. What should I do for querying? You know what they tell us? Well, you've got cursors and indexes. Okay. That's your next question, right? I can kind of mind read while doing the Jedi. I think I kind of mind read. What about complex joins and still no sequel? You can build something on top of it. The reason being, first thing, sequel is not a standard. So sequel is a standard, but the way it's implemented is hard. So picking up sequel is a standard and making every browser vendor to agree on that standard is going to be very hard. So these guys said, we'll give you a basic layer. You've built your querying capabilities on top of it. That's the basic point. So yes. So that's what they said. And well, I said, okay, fine, let me build something. And that's what I have built. The Dark Lord shows, says, show me in that voice, scary voice. And yeah, I will show you. So what is that at the site? Spaceship. Come on. You can do better. What is that? Millenium Falcon. That's the spaceship by Han Solo for Die Hard Star Wars fan. I'm one. So this is actually what Obi-Wan Kenobi says when he sees the spaceship first, but don't worry about it. That's not related to Index D. So what I did was I picked up the Index D B API and wrote a simple link wrapper on top of it. How many C-sharp developers have heard of L-I-N-Q? The others are going to kill me, right? L-I-N-Q. Okay. For people who do not know what link is, it actually sounds like English. So it's something like, from table in database, select something, when something, condition, or order by something. This is how link looks like. Okay. I know what you're looking at next. You'll ask me this, right? Fine. I'm just kidding. This was an example that I wrote. I want to play around with Index D B API. So I wrote this. However, if you want to write a SQL wrapper on top of it, I'd love to partner with you and write that. The first problem that we'll probably have to solve is see how we can make the SQL compatible with everyone. So let me show you what this looks like. And I'll also tell you why I wrote this in the first place. So this is not readable, right? So this is how my link API looks like. What it does is, let me also do word wrap, it says link.link is my workspace. It says to this database or to this object store in this database, add the data, and once you've added, then promise console.info or console.error. So tell me what is this doing? What does this do? To a database, to an object store in a database, add data, what is the typical, what does it do? It saves data, right? It's link that complex. So effectively it tries to save data. So this is the syntax that I came up with to save data and that mimics link. The reason I'm showing you this is if you didn't write this, you'd probably end up writing this. You'll probably end up writing so much of code. So what I wrote was I was writing indexed db applications and I thought that writing so much of code every time is kind of crazy. So I thought let me write an API on top of it and I came up with the link API. So I also have stuff like this. Let's say, let me do this. From object store, order by price reversed and for each print, this is what it looks like. It says from database in bookshop, order by price, one is like zero or one where one is reversed. Select everything and for each of them do a console.info. If you were not to do this, you would effectively end up writing this much of code. So this is one simple example I wrote saying that, okay, this is a simple querying service that I can give you on top. So here you can have stuff like where property equals. You can do stuff like this. So this is a library that I wrote that gives you simple querying capabilities. Moving on. So by the way, if you're actually considering index you could try this out. If you're a fan of link. If you are not, probably God help you. So you saw this, but I know what you're telling me. Link is not my cup of tea. It's hard, right? How about jQuery? So I kind of thought, yeah, fine. I'm also a jQuery guy. I write the same link kind of syntax on jQuery. So I wrote an index dbap on jQuery. Why did I go back? So I wrote a simple jQuery plugin for index db. Let me show you how that looks like. Why has it not loaded? So for example, if you just minimize my browser. For example, if you want to create an object store you do something like this. You say dollar.indexdb.createObjectStore. If you want to say add data let's look at the same add data example. I create a window.book object and I populate it with some random data and I do stuff like in this database, in this object store add this book. Instead of this, if you want to follow the index db way of doing things, index db way of doing things you would probably have to write so much code. So it's a simple jQuery library that I wrote to simplify the way you're working with index db. I'll be having links for both of these libraries at the end of my talk and if you're using index db do which you probably are not going to in the near future. But if you plan to play around with index db you could give a short about to these libraries that I have written. This is actually production ready. I have a couple of my personal projects on index db today is not ready. Major browsers don't support it yet. You will have support like IE10, Firefox 5 plus, Chrome 12 plus. That's kind of not... You don't have support in Opera. It's not production ready but once it gets there I hope this library helps people. So coming back to my presentation I know what you're asking me now. Someone defined the index db library and I don't have faith in them and I've written wrappers on top of it. You know the reason I wrote it? First thing is this there is no joins. Do you think you need joins in index db? How many think you need joins? Just one, two, three, four good. So I tried writing that in link. Probably you could do it in sql but I think we definitely need joins. They suggested doing union and intersection in JavaScript. Well you can do union of two arrays, object arrays that's okay but once it starts increasing your code is going to get bad. There is no full text search if you notice. By the way this was also a proposal. Who do you think or which company do you think proposed or asked for full text search in index db? Oracle Oracle, who else? Yeah, so they effectively wanted to search the index db, right? I mean when you put data you don't want to search. Unfortunately there's no full text search and there's a technical reason to it. The way Microsoft index db is implemented is completely different from is possibly completely different from the way sqlite is and probably sqlite could give you index db search capability but say Google's level db could not, right? So it's a database specific feature that was asked for, it was not taken. Probably in the next version. There's no capability to roll back your database, right? I mean all the dbas love the idea that you go mess up with a client database and then roll it back quietly as if nothing happened. Have you done it on production systems? Deploy something roll back? Well I have done it. Oh yeah, of course everyone has done it. So there's no db rollback. So today if you do this you're pretty much on your own. There are versions supported. So if you change the database schema you can do a set version. I didn't show you the calls but I thought everyone here knew index db. So versions are supported but not fully. And there was one question about syncing with the server, right? Who was that? You wanted to sync with your mothership, yeah. So the question was I have a database on my client and I want to sync it to a SQL server or a MySQL at the server. How do I do it? You will have to write code today. It's actually even worse because there's no change tracking mechanism. So if something changes, if you have 10 tabs and if something changes in one tab if you have like 10 applications on the same domain and if one of them changes it you will have to write custom logic so that everyone else listens. There's no change tracking API. So which effectively means that writing a sync to the server is a very hard thing to do today. It has isolation level but change tracking is different, right? So imagine that four or five people have written it and a new on the same domain you have three applications coming. The first two applications have a contract saying that if I change change something, I'll send you a message. The third guy doesn't know about this contract. It's kind of hard, right? So it has a read, read, read, read, write transaction level but transaction levels are not equal to syncing with the server, right? Because you want to sync whenever something is changed and that will not be possible with this. You would need possibly a row level syncing where you say this row has changed or send it to the server or this row has changed and hence raised an event for me. I could possibly listen in that event and change it, right? Doesn't have that. Yes. Unfortunately, there's nothing like that. And by the way, I said USS Enterprise, no one noticed. How many Star Trek fans here? Good. I said USS Enterprise in the Star Wars convention, but yeah, sorry. I'll just strike it out. And the future is always in motion. All this is good. If you notice one thing, Index DB does not do anything that's related to DOM. It's all JavaScript, right? How does ECMA change it? First thing is, Index DB may become a module. Index DB, rather than using DB request, they can actually fall back on promises which is anyway part of JavaScript. It could actually have iterators and generators instead of cursors, right? That's a good idea to have. It would be able to save binary blobs, which is important. Today, it cannot. But with WebGL, it may be required to save binary blobs, and things like destructuring assignments will be useful. So whenever you read an object, you simply destruct it, and you can read the entire object back. So this may be useful when ECMA 5 comes in. And classes may actually be construed as a way of object schema. Today, there's nothing called object schema in Index DB. Classes could be that. So with this, I leave you, may the force be with you, and this is me. Questions? The implementation across Firefox. So the latest implementation is actually pretty consistent. It is pretty consistent. It is pretty consistent. So spec is in its editor's draft, last call for comments, I guess. You never should believe when these guys say it's going to be done by the end of this year, but that's what they've said.