…DAP (“Device APIs and Policy Working Group”). This thrillingly-named set of specifications is further extending the capabilities of the Web by specifying APIs that allow access to device features like camera, contact books and calendar — much like Geolocation gives browsers access to the device’s GPS capabilities.

http://hacks.mozilla.org/2011/01/people-of-html5-bruce-lawson/

I stumbled on the Mozilla Foundation’s Drumbeat project recently:

Drumbeat gathers smart, creative people like you around big ideas, practical projects and local events that improve the open web.

It’s very well done combination of projects + community.

Drumbeat Toronto Meetup

There’s a whole slew of cool projects already one here. A small sample:

We have been thinking about the app store models for awhile, and how they port to the Web. With the Chrome Web Store we can take a look at a concrete example and think about how it could potentially grow?

Mozilla just came out with a post that aims to start a discussion about what an Open Web Store would mean?:

• exclusively host web applications based upon HTML5, CSS, Javascript and other widely-implemented open standards in modern web browsers — to avoid interoperability, portability and lock-in issues
• ensure that discovery, distribution and fulfillment works across all modern browsers, wherever they run (including on mobile devices)
• set forth editorial, security and quality review guidelines and processes that are transparent and provide for a level playing field
  respect individual privacy by not profiling and tracking individual user behavior beyond what’s strictly necessary for distribution and fulfillment
• be open and accessible to all app producers and app consumers

I personally have been taking apart some of the pieces that make the holistic “app store” experience, and think there is room to do more with the various pieces. I would love your thoughts on what I wrote (pasted contents below):

App Stores. Catalogs. Markets. Gardens. They have been an incredibly hot topic ever since the success of the iPhone App Store. Everyone has wanted to own and control an app store ever since, for many different reasons. Not all of them are good. Not all of them can extract from the App Store experience.

With that, today Google unveiled a Chrome Web Store. Many folks have talked about how the Web, and the Open Web, could benefit from an app store. At a high level, the Web should give developers great options to distribute and monetize (if they so wish) their products, projects, and abilities.

There was a phase where people assumed that Internet meant “everything would be driven to be ‘free’”, and the model to make money is ads. Ads can potentially be a great avenue depending on your product, but people have always been willing to part with money to get value (or perceived value) back… and it shouldn’t be too shocking to have see that play out again via app stores. Deliver great experiences and they may come. There is a lot to be said about “expectations” though, and I feel for some of the business models that are in trouble (media etc).

So, it would be nice if a developer could build something useful, stick a price tag on it, and sell it… using great distribution channels. One model for this is to package the application in a way that works in the distribution channels (e.g. PhoneGap, Titanium, or for us on webOS…. natively) but surely we can do better?

When you look at what an app store is, it consists of many pieces indeed.

For example,

Application Platform

This is the set of APIs and technology that you can use to build your applications. We feel strongly that having many fragmented devices with their own set of APIs, and thus their own platform, is a path to madness. To fix that, we need a unifying platform. We could unify on a proprietary platform (e.g. Flash, Cocoa, Silverlight/.NET, or what have you) or we could learn from history and honour the very lucky place that are in as an industry, and choose Open standards… and in concrete, the Web.

The Chrome Web Store very much honours this. Their apps are just Web apps. This is fantastic and a big step forward. The fact that you could take the same codebase and ship it in a store that runs in Chrome and other browsers (and web OS’s :) is great news.

But this is only one level of the stack.

Application Packaging

How do you package up your application to place in a store? Chrome has a prelim crack at this with their crx format that we have seen via Chrome Extensions. There are also others:

W3C widgets, Android, webOS, Nokia WRT, and more. Libraries like PhoneGap already have to deal with this world. We need scripts and tools to navigate this world. In the short term lets create and use those tools, but how about all getting together and making a format that we can all live with and extend in the right ways?

Distribution

How do you distribute your apps? Right now you either: a) put up a website and folks find you (via search {and thus SEO}, the social web, and links), b) put an application into a store itself.

The Web won on distribution. AOL couldn’t hold back the tide. Everything was Out There. Do we really want one or two companies in charge of what gets Out There? There is certainly value to curation, and finding applications via places you trust, but I personally want to see us solve the problem is a distributed open way. No entity should own the pipe. There should be no “right way” to censor or review applications. Different systems can choose values. Ideally they are transparent, and consumers can then choose where they want to look for the app content.

Discoverability

If we had a standard format for “installable web apps” a lot of good can happen. If we had a standard format, we could annotate the Web with it. Browsers could consume it (e.g. App Discover and the talk on just this.) and search engines could index it.

If I am on a Web site that has an application available, the browser should let me know. If I do a Google search, a one box should tell me about the matching apps for the platforms that I care about.

Anyone could create a merchandising experience and have access to apps to search for. We can go beyond that too of course. We can have web hooks that ping services with information about applications that have been created. A meta service would crop up that looks for the data and then pings the various Web app stores, just like we saw with trackbacks and the like.

There is still a ton of room to innovate in discoverability. Smarter searching that ties deeper than matching on the content will kick in.

Merchandising

Having access to the application data is important. The Palm ecosystem shares full feeds of the data from the catalog and this allows anyone to merchandize the content. They can be creative and present the right content to the user. There is a lot of innovation to be done here. Ideally, someone could create a great new social algorithm and have it run against all of the web apps out there. Right now, the stack is monolithic and we only have basic merchandising needs in most of the ecosystems. What about affiliate systems and the like which could enable innovation here?

Fulfillment

How do you pay for a good. How does the developer get paid for the good. This is an obviously crucial layer. Apple has done very well because people already had iTunes accounts coming into the world of the iPhone. In a distributed model, users could choose to fulfill via Amazon, or Paypal, or Checkout, or SimpleBank (one day right al3x? :)

And more….

We haven’t even gotten into identity, single sign-on, reputation systems, and how reviews can be shared on the same applications in different stores. There is so much to be done here.

Looking forward, where does this next step take us? Is there a path where web applications themselves are back to just being websites that can live in various stores, and a pay gate can be setup in an easy way?

I can’t wait to see how this plays out. We could all go off and build ivory towered app stores, or we could come together and work out a better way. Are you in?

The initial work has been taken to the next level with the Account Manager Add-on by Dan and co:

How Does It Work?

The Account Manager specification proposes two small changes to Web sites:

1. The browser needs to know how to register, sign in, and sign out of your site. You will need a static JSON document, automatically discovered by the browser, which describes what methods the site supports and how they should be executed. For example, a web site might describe their support of “connect” (sign in) like this:
   PLAIN TEXT
   JAVASCRIPT:

   1.  
   2.   "methods": {
   3.     "username-password-form": {
   4.       "connect": {
   5.         "method": "POST",
   6.         "path": "/accounts/LoginAuth",
   7.         "params": {
   8.           "username": "Email",
   9.           "password": "Passwd"
   10.       }
   11.   }
   12.  

   This example tells the browser that the site supports signing in with a form POST to /accounts/LoginAuth, and what parameter names to use for the username and password (Email and Passwd respectively).

2. The browser needs a way to check which user (if any) is currently signed in. To do this, you need to set an HTTP header in the same code where you would set a cookie with a session ID. If you can’t set an HTTP header, you can also supply a URL the browser will ping.

   The header would look like this:

   X-Account-Management-Status: active; name="Joe User"
   

   That would tell the browser that “Joe User” is now signed in, so it can provide the appropriate UI (to switch users or sign out).

Read the full specification for more.

As part of their on-going efforts to engage directly with the web developer community, Mozilla hosted a Web Caching Summit earlier this week to discuss how the web platform could better meet the needs of developers. In attendance were developers who work on Facebook, Google Search, Microsoft Office Live, Twitter, Yahoo, SproutCore, and Palm webOS. Arun Ranganathan moderated the gathering.

One of the core challenges identified by the group was that frequent visitors of a site are often missing resources in their browser cache that the site authors think should be there. In other words, why is the same user requesting a static cacheable image with a year-long expiration every few days?

A lively discussion ensued over 5 hours talking about this problem and others, touching on why this is the case and what page developers could do to maximize the cache-ablity of their websites.

A high-level summary of the outcome is:

- browsers should immediately investigate increasing the size of the browser cache
- Mozilla will learn more about caching behaviors in the browser, perhaps by using Test Pilot to collect more information from end users
- Mozilla will investigate means of prioritizing content in the cache, either by allowing developers to prioritize content (i.e., set some content on the page as a higher cache priority than others) or through implicitly prioritizing (e.g., CSS and JS above images).

What do you think browser vendors could do to improve caching?

We have seen :visited sniffing for good as well as ill (Aza wrote about using it to detect what networks you are on which can help you put up the right badge in an OpenID signup say) but it is a loophole that many want to fix.

The fix could affect you though. Here is what is changing:

These changes will have some impact on web sites and developers, so you should be aware of them. At a high level here’s what’s changing:

• getComputedStyle (and similar functions like querySelector) will lie. They will always return values as if a user has never visited a site.
• You will still be able to visually style visited links, but you’re severely limited in what you can use. We’re limiting the CSS properties that can be used to style visited links to color, background-color, border-*-color, and outline-color and the color parts of the fill and stroke properties. For any other parts of the style for visited links, the style for unvisited links is used instead. In addition, for the list of properties you can change above, you won’t be able to set rgba() or hsla() colors or transparent on them.

These are pretty obvious cases that are used widely. There are a couple of subtle changes to how selectors work as well:

• If you use a sibling selector (combinator) like :visited + span then the span will be styled as if the link were unvisited.
• If you’re using nested link elements (rare) and the element being matched is different than the link whose presence in history is being tested, then the element will be drawn as if the link were unvisited as well.

For some time now, Adobe has been working with platform vendors to include the Flash plug-in pre-loaded. We've seen this ages ago in Windows, and more recently with Adobe's efforts in the Open Screen Project.

Now, there's news of something a little bit different. In our second Google-y post of the week, there's the news that Chrome now embeds Flash directly in the browser, starting today with the developer channel builds of Chrome.

While this doesn't change the game for developers--it won't materially impact Flash market share--it certainly provides a much more pleasant integration for users who will no longer need to think about updating Flash as a separate process to updating their browsers. (And since Chrome auto-updates, it's blissful upgrading indeed.)

Plug-ins with a Dash of Pepper

What *may* impact developers more is news of Adobe working with Google and Mozilla to create a new, deeper browser plug-in API. While no timelines are given, some technical details are provided via a Mozilla Wiki page.

Code-named "Pepper", the API provides all kinds of goodies denied to plug-ins before, such as using native GUI controls inside of a plug-in (i.e., scrollbars) instead of being forced to render its own and access to printing and the clipboard. Pepper also provides granular media APIs instead of forcing plug-ins to deal with graphics and audio on its own.

It will be interesting to see how successfully such an API can be implemented consistently cross-platform, but at first glance it seems to embrace about the right set of trade-offs.

They just released an alpha add-on for Firefox that begins to integrate contacts from services (right now: "Gmail, Twitter, and, on MacOS-based machines, the local Address Book" but growing).

Imagine getting auto-complete across all of your forms... like this:

Here is a list of features:

• A browser-based Contacts database that stays in sync with your address books (so far, it supports GMail, Twitter and Mac OS Address book)
• A generic importer system for Contacts from desktop or web-based address books (so you can implement missing ones)
• An email autocompletion feature, which demonstrates how the browser can auto-complete email addresses on any website. The autocompletion is performed entirely in the browser, without sharing the your list of contacts with the website.
• A Javascript API that websites can use to access the Contacts database, with explicit user permission and filtering

Download it here.

This is very cool and you should also note the open technology being used:

• We’re indebted to our friends and colleagues at Mozilla Messaging, who have been working on address book integration in Thunderbird for years, and have the exciting new Raindrop messaging application in experimental development now. We are working on integrating the Raindrop project with the Contacts API!
• The Portable Contacts initiative is an important effort to define a common data definition for contact data. We use the Portable Contacts definition internally for Contacts.
• The W3C Contacts initiative is defining an industry-standard, cross-platform API for access to contact data in the browser. The spec is new and evolving, and now is the time to experiment and provide feedback!

We now have Jetpack SDK with a brand new architecture.

Two videos really show off the thinking.

Firstly, Atul Varma, tech lead for the project, talks through the update and how you go about using Jetpack SDK. There are some cool new tools revolving around developer ergonomics. These tools help with the packaging of code, developing of code, documenting code, and the management of code. The screencast below shows you how to create a module, using CommonJS at the heart of it.

The next video is from Aza and is typical Aza. It is creative. He walks through the architecture.... why the reboot happened, and what has changed, but instead of a talking head, we get Aza's hands and pencil drawings. Oh, and he has some glasses on the top right, showing us that he has thought hard about this. :)

Exciting to seeing Jetpack come up for air again, and I can't wait to see it quickly iterate from here. For more information check out the release notes, the FAQ, and download the SDK and write an extension.

David Anderson: "TraceMonkey has rocket boosters, so it runs really fast when the boosters are on, but the boosters can’t always be turned on."

Opera's new JIT compiler Carakan is doing well as we just posted. What is Mozilla doing with TraceMonkey? A lot.

Mozilla JägerMonkey adds method based JIT (of V8 and Nitro fame) to keep the boosters on.

We learn more from David Mandelin and David Anderson.

Mozilla Labs has released the magical 1.0 version of Weave and the doors are now open for developers.

When I was a part of Mozilla Labs day to day, I always loved the vision and team behind Weave. I kept wanting the implementation to match the vision, but it is a tough problem and it takes time to bake. Well, it is getting there now.

Weave is special because it offers a series of back-end services (more than just sync) that are build with users (and their privacy) in mind, rather than business models. I have talked to a couple of entrepreneurs recently and thought that there ideas could be implemented nicely on top of Weave.

It is still early days, but I am jazzed to see the platform getting opened up. I am hoping to get clients for Safari, Chrome, and IE.... and look forward to a webOS client too :)

Robert O'Callahan (moz layout guru) shares why he thinks Mozilla should stand firm on the H.264 issue comparing it to the ActiveX issue from the past.

With Chrome and Safari supporting H.264 (and not open video formats such as Ogg Theora) some users and developers have asked for Mozilla to support it too in Firefox. Mozilla is certainly a user-centric group (which is how they have gotten so far with Firefox) but remember that they are mission based: to keep the Internet open.

Here is some of RoCs opinion. I am glad he shared it:

Taking such positions is nothing new for Mozilla and history has proved us right for doing so, in particular regarding ActiveX and Web standards in general.

Perhaps it's not widely known, but Gecko has had code to support hosting ActiveX controls, dating back as far as 1999. ActiveX controls are very much like system video codecs. ActiveX support would have been very useful to users ever since 1999, and still would be now --- certainly in corporate intranets, and everywhere in China and South Korea. Enabling ActiveX support would probably boost our market share significantly. Most users have useful ActiveX controls on their machines. But for the last ten years, even during Mozilla's most desperate days, we have consistently refused to turn this feature on, because we believe that ActiveX is not good for the Web.

I'm not suggesting that the consequences of exposing system codecs to the Web would be identical to exposing ActiveX. That's unlikely, and unknowable. But favouring our principles over short-term gains for users is nothing new for Mozilla, and when we've done it in the past, history shows it was the right thing to do.

Chris Blizzard has a very detailed perspective too, linking up the history of GIF, MP3, and On2 :)

According to The Register, Mozilla may soon build a marketplace for add-ons:

Mozilla has said it will "probably" open a marketplace for Firefox add-ons sometime next year.

Add-ons product manager Justin Scott (reluctantly) announced the news this morning at an add-on-happy conference in Mozilla's home town of Mountain View, California. "We'll probably be doing a marketplace pilot in 2010," he said.

Scott did not provide details. But earlier in the morning, he did say that Mozilla has no intention of using DRM - not that you would have expected anything else. "I don't know what we'll do, but we won't do DRM," he said.

It wouldn't be too surprising to see Moz bolt in a payment model to the existing add-on repo, which already has a review process. Of course, once you start paying developers to build add-ons, many more add-ons will need to be reviewed and Mozilla will have to make tough decisions about to what extent add-ons will be reviewed, if at all, and what kind of charge, if any, will be imposed on add-on providers.

There are already some browser extensions that come with a price tag. This happens in both IE and Safari, both browsers lacking a vibrant extension community; and it also happens with Firefox, where there is a vibrant community of typically free, open-source, extensions.

An add-on marketplace would formalize the payment model and add a big incentive for developers to build seriously useful add-ons, given the possibility of reaching a market in the hundreds of millions. The flipside is that we might no longer see free versions of some of our favorite add-ons. Given its open-source DNA, it might be nice to see a "donate" button beside any of the free offerings in the store. (Update: Ryan Doherty points out in the comments there's already an add-ons contibution feature, pilot launched in July.)

It's also interesting to consider how an app store might open up a marketplace for new types of add-ons. For example, if you see the browser as a convenient sandbox to drop small desktop apps into, we could end up with simple games and utilities which might otherwise be released as shareware. Print-on-demand might be another application.

This is all hypothetical for now, but it's still fun to speculate on what could become of AMO!

At the high level:

• Users can now change their browser’s appearance with a single click, with built in support for Personas.
• Firefox 3.6 will alert users about out of date plugins to keep them safe.
• Open, native video can now be displayed full screen, and supports poster frames.
• Support for the WOFF font format.
• Improved JavaScript performance, overall browser responsiveness and startup time.
• Support for new CSS, DOM and HTML5 web technologies.

But there is so much more. There is a ton of CSS work including background-size, gradients, and multiple background images. Video can now have a poster frame, HTTP activity can be monitored, Web Workers can self-terminate with close(), drag and drop supports files via DataTransfer, window.onhashchange.

As well as the nice new look, there is a new API with nice methods such as getObjectTable that includes a lot of great work such as looking at the shape of objects and deep understanding of the platform to let the real information rise to the top.

Install the add-on and enjoy Atul's code.

People have focused on the new CSS improvements (Acid3 now gets 94/100) such as the tweaked CSS gradient support:

We also get new background rules such as background-size and multiple backgrounds.

Read more 3.6 for developers info:

• The background-size property from the CSS 3 Backgrounds and Borders draft is supported under the name -moz-background-size .
• A proposal for CSS gradients is supported for background-image .
• Multiple background images are now supported.
• The rem length unit from CSS3 Values and Units is now supported.
• image-rendering is supported for images, background images, videos and canvases.
• text-align :end is now supported
• DOM changes to elements using the table display types now work much better.

• You can determine whether or not content is being rendered on a touch-enabled device using the new :-moz-system-metric(touch-enabled) selector.

• The reorder event is now sent to embedded frames and iframes when their document is loaded. See
  bug 420845.
• The getBoxObjectFor() method has been removed, as it was non-standard and exposed even more non-standard stuff to the web. See
  bug 340571.  Also affects mootools which uses this call for Gecko detection.  See this mootools bug.
• A new attribute has been created, mozScreenPixelsPerCSSPixel, for obtaining the amount of screen pixels per CSS pixel on nsIDOMWindowUtils . This can be used in conjunction with the new global properties, mozInnerScreenX and mozInnerScreenY, to compute screen coordinates. See

  bug 486200 and
  bug 507755.

• When the page's URI's document fragment identifier (the part after the "#" (hash) character) changes, a new hashchange event is sent to the page. See window.onhashchange for more information.
• Geolocation "address" support is now available enabling user-readable position information.  See

  bug 503942.

• The attribute document.readyState is now supported. Gecko also supports document.onreadystatechange now.
• Support for HTML 5's element.classList to allow easier handling of the class attribute.

With the Jetpack 0.4 release we see two cool APIs:

Audio Recording API

We have a shiny new <audio> tag which is great for playing audio and all, but how about adding the ability for users to easily create audio?

The new Audio Recording API lets you do just that:

Play the local file back with jetpack.audio.playFile() or upload it and just use the audio tag itself.

A great showcase of this is the voice memo jetpack "which lets you annotate any webpage you are looking at with your voice." Live streaming is even coming soon. Here comes video conferencing the Open Web way?

Page Mods API

Jetpack is a great way to do Greasemonkey-like work. To make it even easier, you need a way to define when the jetpack kicks in etc, and this is exactly what the Page Mods API gives you.

Check out the blacklist example:

Nice work guys.

Over at the Mozilla Labs blog, we just launched an "Open Web Tools Directory". Running Ajaxian for the past few years, we've discussed a legion of developer tools of all shapes and sizes, but there are so many we've quickly lost track of all that's available.

With the Tools Directory, we hope to provide a central location where the community can track what's happening in the tools space. At Mozilla, we release early and often in the open-source tradition, so what we've launched is the first step in the journey. We'd love to get your feedback in this early stage as we evolve the directory.

We've got nearly 70 tools in the database so far, but that's just a small fraction of the hundreds of tools out there. Would you help us out and tell us about your favorite tool(s)? (We're still working out infrastructure, but eventually we'll have a way to own a tool and keep its metadata up-to-date. And our sincere thanks to Laura Thomson who worked very hard to help us get the infrastructure and back-end for the directory ready.)

Dion and I both have some corporate IT experience under the belt, and because of that we just couldn't bring ourselves to write yet another typical table-based database CRUD app; hence, the space theme and gratuitous canvas-based UI. So the Tools Directory is our second canvas-centric web application released this year, but we promise to use the DOM API more for the next one. ;-)

Implementation Details

We knew we wanted to do some kind of space-themed design for the directory involving images for the tools flying around, but we weren't sure how much performance we could get out of canvas. Some of our previous experiments have shown that we can repaint a large canvas many times per second, but how many individual images could we paint per frame full-screen and still get decent perf? This experiment, representative of several we whipped up, was somewhat promising: we're able to draw and scale about 700 images about 20 times per second.

Based on these results, we thought we could get away with a "warp-in" effect flying in maybe one or two hundred images and get decent frame rates. To make the effect somewhat predictable, we based the animation effect on clock time with the result that it drops frames rather than alters the speed of animation when the browser can't keep up with the requested workload.

Unfortunately, once we implemented the effect, we discovered that we started to get choppy performance with only forty or so images (all of our tests are using recent-model MacBook Pros running OS X and Firefox 3.5 or Safari 4). Our test images were 32x32, but once we switched to 128x128 images, performance suffered dramatically. We haven't looked into it further, but the degradation may be linear according to image size.

We had always planned on caching aggressively, but these results indicated just how much caching we'd have to do: lots.

So we implemented the directory in such a way that at any time, we can cache the state of the canvas animation and exclude arbitrary elements from the cache. This is how we implement various features like selecting a subset of the items and moving them to the center of the screen when you search the directory, for example:

We also added a staged introductory fly-in effect where only a subset of the tools fly in and we cache the screen state and then fly in others, keeping the overall number of items to animate low--but the effect is presently disabled. Look for it in a future release as we expand the catalog of tools further. We'll have to work something out because flying just 70 items at once produces choppy animations on the fastest hardware using the fastest browsers available.

For the time-based animations, we implemented a simple timing framework. We wanted to grab an off-the-shelf library, but of the half-dozen JS animation frameworks we analyzed, all of them assumed we were animating DOM nodes or changing single object properties, which made their use somewhat obtuse. We really just wanted a simple callback for each frame in the animation. (We also grabbed the GX framework's easy-to-grab ports of Robert Penner's easing equations.) We'd love to replace our timing framework with something more sophisticated and actively maintained; let us know if you've got something we can use. In particular, we'd like a framework that intelligently reports the minimum resolution required by all currently scheduled timing jobs.

On that note, the other interesting bit for us was working out how often to repaint the canvas. After experimentation, we settled on using setInterval to repaint the scene every 20 ms. This has the unfortunate side effect of hitting the CPU rather hard during the animations and so forth.

Future

We're really excited to add a bunch of community features to the directory. We want folks to vote on tools, comment on them, submit and maintain them, and so forth. But in addition to that, we want to enable sub-universes; e.g., we want to track plug-ins for tools like Prototype, jQuery or Firebug so you can explore those universes within the framework of the overall directory. And if there's interest, we'd love to make it even more general and release the "universe browser" framework for anyone that wants to use this interface to explore taxonomies.

On a technical note, we're really keen to see how the DOM would perform relative to canvas, and how 3D approaches (e.g., using Mozilla Firefox and Google Chrome's 3D support) work out. Oh, and we're going to release an accessible, non-graphical version of the directory soon as well.

Please tell us what you think, and we hope all of us will be able to make use of this framework to help keep track of the exploding universe of web developer tools. Thanks!

Slidebar isn't a spelling mistake, but a slightly different take on the traditional sidebar. Check out Aza in his screencast to see them in action, and wait for the part where he sucks in a playing video and lets you continue to browse the Web elsewhere.

To code up a slidebar you simply:

but you have to use another new feature of Jetpack 0.2.... future:

Jetpack is two things at once: it is a platform for experimentation and it is also a solid set of APIs that anyone to easily build new Firefox features. To enable Jetpack to be both stable and — at the same time — to experiment with not-quite-yet-ready features we’ve added the ability to import new features from the “future”.

Slidebars, for example, are still highly experimental. To use them, you need to import them from the future first.

Read more about future in the Jetpack enhancement proposal (JEP) for jetpack.future.

jetpack.future.import("slideBar")

Persistent Storage and Clipboard Support

One of the most requested features in the Jetpack development mailing list was for the ability to persistently store data across restarts.

We’ve added simple storage to the future module. The API is defined in the storage JEP. Using it as simple as:

jetpack.future.import("storage.simple");
var db = jetpack.storage.simple;
var data = {name: "Firefox", twitter: "@firefox"};
db.set( "friend", data );

Give it a go!