Month: October 2012

What is Jetpack here for?

Who are the Jetpack team? What are they here for? A lot of people in Mozilla don’t know that Jetpack still exists (or never knew it existed). Others still think of it as the original prototype which we dropped in early 2010. Our goals have changed a lot since then. Even people who think they know what we’re about might be surprised at what our current work involves.

Let’s start with this basic statement:

Jetpack makes it easier to develop features for Firefox

There are a couple of points wrapped up in this statement:

  1. The Jetpack team doesn’t develop features. We enable others to develop features. We should be an API and tools team. We’ve done a lot of API development, but we should work with the developer tools team more to make sure that Firefox developer tools work for Firefox development, too.
  2. I didn’t say “add-ons.” I said “features”. The APIs we develop shouldn’t be just for add-on developers, Firefox developers should be able to use them too. If the APIs we create are the best they can be, then everyone should want to use them. They should demand to use them, in fact. It follows that this should make it easier for add-ons to transition into full Firefox features, or vice versa.

We happen to think that a modular approach to developing features makes more sense than the old style of using overlays and xpcom. All of the APIs we develop are common-js style modules (as used in Node and elsewhere) and we’ve built the add-on SDK to simplify this style of add-on development. That work includes a loader for common-js modules which has now landed in Firefox and is available to all feature developers. It also includes tools to take directories of common-js modules and convert them into a standalone XPI that can be installed into Firefox.

The next step in supporting Firefox and add-on developers is to land our APIs into Firefox itself so they are available to everyone. We hope to complete that by the end of this year and it will bring some great benefits, including smaller add-ons and the ability to fix certain problems in SDK based add-ons with Firefox updates.

Mythical goals

Jetpack has been around for a while and in that time our focus has changed. There are a few cases where I think people are mistaken about the goals we have. Here are the common things that were talked about as hard-goals in the past but I don’t are any longer.

Displace classic add-ons

Most people think Jetpack’s main goal is to displace classic add-ons. It’s obvious that we’ve failed to do that. Were we ever in a position to do so? Expecting the developers of large add-ons to switch to a different style of coding (even a clearly better one) without some forcing factor doesn’t work. The electrolysis project might have done it, but even supporting e10s was easier than converting a large codebase to the add-on SDK. The extension ecosystem of today still includes a lot of classic addons, and the APIs we build should be usable by their developers, too.

Forwards compatibility

Users hate it when Firefox updates break their add-ons. Perfect forwards compatibility was another intended benefit of the SDK. Shipping our APIs with Firefox will help a lot, as the add-ons that use them will work even if the specific implementation of the APIs needs to change under the hood over time. It won’t be perfect, though. We’re going to maintain the APIs vigorously, but we aren’t fortune tellers. Sometimes parts of Firefox will change in ways that force us to break APIs that didn’t anticipate those changes.

What we can do though is get better at figuring out which add-ons will be broken by API changes and reach out to those developers to help them update their code. All add-on SDK based add-ons include a file that lists exactly which APIs they use making it straightforward to identify those that might be affected by a change.

Cross-device compatibility

There’s a theory that says that as long as you’re only using SDK APIs to build your add-on, it will magically work on mobile devices as well as it does on desktop. Clearly we aren’t there yet either. We are making great strides, but the goal isn’t entirely realistic either. Developers want to be able to use as many features as they can in Firefox to make their new feature great. But many features in one device don’t exist or make no sense on other devices. Pinned tabs exist on desktop and the SDK includes API support for pinning and un-pinning tabs. But on mobile there is currently no support for pinned tabs. Honestly, I don’t think it’s something we even should have for phone devices. Adding APIs for add-ons to create their own toolbars makes perfect sense on desktop, but again for phones makes no sense at all.

So, do we make the APIs only support the lowest common denominator across all devices Firefox works on? Can we even know what that is? No. We will support APIs on the devices where it makes sense, but in some cases we will have to say that the API simply isn’t supported on phones, or tablets, or maybe desktops. What we can do, again by having a better handle on which APIs developers are using, is make device compatibility more obvious to developers, allowing them to make the final call on which APIs to employ.

Hopefully that has told you something you didn’t know before. Did it surprise you?

Simple image filters with getUserMedia

I forgot to blog about this last week, but Justin made me remember. The WebRTC getUserMedia API is available on the Nightly and Aurora channels of Firefox right now and Tim has done a couple of great demos of using JavaScript to process the media stream. That got me interested and after a little playing around I remembered learning the basics of convolution image filters so I thought I’d give it a try. The result is a sorta ugly-looking UI that lets you build your own image filters to apply to the video coming off your webcam. There are a few pre-defined filter matrices there to get you started and it’s interesting to see what effects you can get. Remember that you need to enable media.navigator.enabled in about:config to make it work.

The downside is that either through me not seeing an obvious optimisation or JS just being too slow right now it isn’t fast enough for real use. Even a simple 3×3 filter is too slow on my machine since it ends up having to do 9 calculations per pixel which is just too much. Can someone out there make it faster?

Update: The ever-awesome bz took a look and pointed out three quick fixes that made the code far faster and it now runs almost realtime with a 3×3 filter for me. First he pointed out that storing frame.data in a variable outside the loops rather than resolving it each time speeds things up a lot. Secondly apparently let isn’t fully supported by IonMonkey yet so it switches to a slower path when it encounters it. Finally I was manually clamping the result to 0-255 but pixel data is a Uint8ClampedArray so it clamps itself automatically.

Six hour chilli

I’ve enjoyed making and eating chilli ever since I was in university. It has a lot of appeal for your average student:

  • You can make it in bulk and live off it for a few weeks
  • You can make it spicy enough that you start bleeding out of your nose (and thus totally impress all your friends)
  • It’s dead simple and really hard to screw up

The great part is that really once you have the basic ingredients you can just go nuts, vary up the ratios, add extra bits and pieces, whatever you fancy. Eventually though I discovered that I was getting a bit too wild and really wanted to nail down a basic “good” recipe to work from. It took a couple of tries but here it is. It’ll take around six hours to cook, an extra hour for prep depending on how lazy/drunk you are.

Ingredients

  • 2 cups chopped onions
  • 2.5 lb lean ground beef

 

  • 56 oz diced tomatoes (canned works just fine)
  • 2 tsp chilli powder
  • 2 tsp chilli pepper flakes
  • 1 tsp ground cumin
  • 1 tsp cayenne pepper
  • 1/8 cup cilantro leaves (I use dried but fresh is probably good too)
  • 1/2 tsp chipotle chilli pepper powder
  • 1/2 pint stout or other dark beer
  • 2 cups red wine (I tend to use merlot)
  • 2 cups beef broth
  • 1/8 cup tomato puree or 1/4 cup tomato ketchup
  • ~3-4 tsp coarsely ground black pepper

 

  • 3×12 oz cans of mixed beans
  • 2-3 large bell peppers (red and/or green), chopped

Instructions

  • Fry the onions in some olive oil until they start to turn translucent, then throw in the beef and stir until it browns all over.
  • Add into a large pot with the tomatoes, spices, wine, beer and broth
  • Cover and simmer for 2 hours, stirring periodically (use the remains of the stout to help you get through this)
  • Drain and add the beans
  • Cover and simmer for 2 hours, stirring periodically (it’s possible you’ll need more stout)
  • Add the chopped peppers
  • Cover and simmer for 1-2 hours, stirring periodically
  • Serve with cornbread and the rest of the bottle of wine

Tips

  • This makes a lot of chilli, make sure you have a large enough frying pan and pot. You can try scaling it down but I find it works best when making it in large quantities.
  • After adding the peppers you’re basically simmering till it is about the right consistency, uncovering and/or adding some corn starch can help thicken it up at this stage.
  • This recipe comes out pretty spicy, you might want to drop the chipotle chilli pepper power if that isn’t your thing.
  • Unless you are feeding an army make sure you have tupperware to hold the leftovers. It reheats very well, if using a microwave throwing a little extra water in helps.