Older blog entries for cananian (starting at number 91)

Introducting the XOrduino! (and XO Stick)

I banged out two open hardware designs this week, designed for use with the OLPC XO laptops.

The first is the XOrduino, a stripped down low-cost Arduino-compatible board that plugs right into the XO's USB ports. But wait, there's more: it's also compatible with the Scratch Sensor Board, so you can use this device to control Scratch (and Turtle Art, once Firmata is ported). It should be compatible with the Arduino IDE and all Arduino Leonardo-compatible shields.

The board uses mostly through-hole parts, with one exception, and there are only 20 required components for the basic Arduino functionality, costing about $5 (from digikey, quantity 100). It is reasonable for local labor or even older kids to assemble by hand.

It's open hardware: Eagle design files are on github (schematic PDF, pcb PDF). I expect to have a small number of boards in a few weeks; let me know if you'd like one in exchange for help with hardware and software bring-up. Schematic and layout review also appreciated (I did the PCB routing late at night under time pressure leaning heavily on autoroute, it's certainly not the prettiest). And feedback from Arduino and Arduino shield hackers would also be welcome.

If $5 per student is too much money, there's also the XO Stick, my second board. It's based on the AVR Stick using the ATtiny85 processor and costs only $1/student. It's not quite as user-friendly as the Arduino-compatible board, but it can also be used to teach simple lessons in embedded electronics. For $0.12 more you can populate an ATtiny261A (though a '461 or '861 would be better) and get 13 I/O ports; this variant should be powerful enough to program other XO Sticks and perform XO maintenance tasks (accessing the serial console, debricking a laptop via SPI flash). The XO Stick is even easier for a kid to assemble themself: only 8 required components, all through-hole. (Sadly, my desire to shave every penny off the cost of this design meant that I couldn't use some of the symmetry tricks I invented for a 2012 Mystery Hunt puzzle to make the circuit impossible to assemble incorrectly.)

Same deal as the XOrduino: design files on github (schematic PDF, pcb PDF); I expect to have a few boards available to people who want to help make some software for them. Schematic and layout review is also appreciated!

Syndicated 2012-06-09 16:06:32 (Updated 2012-08-02 18:33:58) from Dr. C. Scott Ananian

Growing Up With Nell

Chris, Michael, and I just submitted a short paper describing our work on the XO-3 Nell project to this year's Interaction Design and Children conference. Give the preprint a read: Growing Up With Nell: A Narrative Interface for Literacy [pdf].

We're hard at work implementing Nell. We could use help in a number of areas: art, animation, story, user interface, javascript hacking, and probably others. For example, at the moment Chris and I are: drawing the characters, drawing user interface concepts, writing silly alphabet stories, animating the silly alphabet stories, doing the CSS/HTML layout to mock up designs, making some of the mock ups into functional demos, implementing HMM-based handwriting recognition in JavaScript, porting pyaiml to JavaScript, implementing an Apple Guide-style contextual help system on top of HTML widgets, and writing a integrated story editor (and stories about the story editor). I'd welcome volunteers for any of these tasks!

Syndicated 2012-03-12 20:55:35 (Updated 2012-03-14 00:28:51) from Dr. C. Scott Ananian

2012 Mystery Hunt

This year I was a member of Codex, the writing team for the 2012 Mystery Hunt. I'm going to describe some of the puzzles I wrote for "The Producers" hunt, in release order. BEWARE SPOILERS!

1. One of the early theme proposals for our hunt was "Alice in Wonderland." Casting about for novel meta ideas, I hit upon the idea of a round with purely numeric answers, 1 through 29,394, which would resolve to words via "looking glass numbers"—that is, numbering all the words in "Through the Looking Glass". It occurred to me that you could make your numbering system self-descriptive if you used certain words; for example, if you wanted to make clear that hyphenated words should be counted as one (instead of two), you could include "great" and "half" on either side of "arm-chair". The numbering of "great" (164) and "half" (166) would make it clear that "arm-chair" should be treated as a single number (165).

   This didn't survive as a meta, but it eventually became a puzzle, called 1207 1370 (which translates to "Looking-Glass Words" using its enumeration system). It also served to ensure that teams had a good wordlist by the time they got to the Charles Dodgson meta...

2. Blinkenlights. A recursive-structured puzzle inspired by (but not reaching the greatness of) Derek Kisman's Maze from Setec's '05 Hunt. If anyone is mourning the lack of Jonathan Coulton-related puzzles from this year's hunt, blame me: I stole the answer PROTECTORS which Andrew Lin had earmarked for a JoCo puzzle. ("Did I say overlords?")

3. Caterpillars. I like giving physical objects to teams. This was another failed meta—you would have assembled the pieces out of words, then would have to assemble the jigsaw from the word-pieces. The location of the caterpillars' heads in the final assembly would spell out the final meta answer using an overlay. But the puzzle is more fun with tangible pieces, I think.

4. B.J. Blazkowicz in ‘Wintertime for Hitler’. I was writing the meta for this round and trying to find non-dictionary words. I needed "CAR..." as a prefix to make the chess game work, which suggested CARMACK as an answer, and the puzzle just wrote itself from there. Scott Handelman contributed the title. This puzzle was going to be distributed on 3.5" disks (remember how I said I like giving teams physical objects?), but the last 3.5" floppy disk puzzle was Blue Steel in '06. (Redundant Obsolescence doesn't count, since the 5 1/4" disk was redundant.) The past six years have not been kind to the 3.5" floppy; ultimately we decided we didn't want to deny teams the pleasure of playing the game because they couldn't locate a floppy drive. It's more important that puzzles be fun than hard!

5. Charles Lutwidge Dodgson meta. I began writing this puzzle immediately after the 2011 hunt, dissatisfied with the mechanism and final clue phrase of that year's Racking Your Brains. I thought I could write a better puzzle using Scrabble Solitaire as a mechanism.

   Slightly later it became part of the "Alice in Wonderland" theme proposal, with Jabberwocky words. Then I spent a couple of months away from the hunt, getting married.

   Upon returning we badly needed critic metas so I dusted off the puzzle, adding an Alice chess frontend yielding the tile string in order to make it a shell meta. The puzzle can still be solved as pure Scrabble Solitaire (ie, without the given "scores after each play") but it's easier for humans to solve with the frequent checkpoints given. For what it's worth, I constructed the chess game with a reasonably-deep alpha-beta search, so all the moves "make sense" as much as is possible given the constraints of the puzzle. And it ends in a clean checkmate, obviously... I have no idea how BENOISY snuck in there.

6. Ben Bitdiddle meta. The idea of making an electronic circuit which was impossible to assemble incorrectly had been in my "Mystery Hunt ideas" folder for years. A coworker at OLPC mentioned the odd power-pin configuration of the PIC chips one day, which gave me the "flip" mechanism. Brainstorming with Andrew Lin brought it the rest of the way.

   I promise never to abuse an optoisolator in this way again.

   (Of course it turned out when constructing this puzzle that Ben Bitdiddle really needed to use the show answers CARPAL and THESOUTH because of their length in morse code, so I ended up having to rewrite parts of Dodgson to make Bitdiddle work. In the rewrite CARPAL became CARMACK... and B.J. Blazkowitcz was born.)

7. JFK SHAGS A SAD SLIM LASS. One of my earliest puzzle submissions was, "A puzzle contained only in its title." Again, the fabulous Codex editor team turned this into a real puzzle.

Some puzzles I enjoyed editing:

1. Revisiting History — I commissioned a Doctor Who-themed puzzle for the answer TORCHWOOD (see the final clue phrase for the reason why) and contributed the "location of the word 'who'" mechanism.

2. Gibberish and More Gibberish. I liked the idea for this puzzle enough that I shoehorned a suitable answer into the Charles Dodgson meta... and then had to do some heavy lifting to get the puzzle finished and into the hunt.

3. Sounds Good to Me. It was immediately obvious this was a brilliant idea from Seth Schoen. But the twin barriers of toki pona and hiragana threatened to make it unsolvable. I'd like to think I played a role in making this an accessible and solvable puzzle.

4. Itinerant People of America. Same deal. Squiggles had bequeathed the world the facial expression described as, "That's my brain leaving out the back door while my face distracts you." My contribution here was solely instilling the fear of God into the authors. Scott Handleman describes how he and Emily Morgan took that advice and constructed a kick-ass puzzle.

And that's it for my puzzles! I also did a heck of a lot of other stuff for the hunt; I hope y'all enjoyed it. (My own favorite part was the wrap-up, since all my responsibilities had been discharged by then. I could just watch Patrick rock my hat and accordion, play along on ukulele, and sing tenor with Francis at the end.)

Syndicated 2012-01-18 23:09:41 (Updated 2012-01-18 23:11:16) from Dr. C. Scott Ananian

A collection of Nell demos

Here are some banged-together demos of various pieces of One Laptop per Child's Project Nell. The ultimate goal is a Nell demo for CES in January 2012, but these bits should be considered as tech demos, benchmarks, and proofs of concept, not actual pieces of that demo (yet).

Most of these demos require WebGL support. Visit get.webgl.org for information about enabling WebGL in your browser; there is WebGL support in Chrome, Firefox, Safari, and Opera—although it often requires enabling experimental features in the browser preferences.

• Tiles. Performance benchmark for a tile-based home screen. "Apps" are "locations" on your world map, which you can customize as you like. (Here's an interesting blog entry discussing world-creation for kids.) Day/night would ultimately reflect current time, although they've been greatly sped up in this demo. Lots of rough edges and missing UI, but all the textured triangles are present, so it should be an accurate benchmark.
  (Drag with left mouse button to rotate, middle mouse button to zoom, right mouse button to pan.)
• Nell at home. Basic idea (including transition) for activities which include dialog with Nell or story-telling.
  Standalone model viewers: Castle (from blendswap), "Nell" (Sintel, from blendswap), Alternate (lightweight) Nell model, Alternate (heavyweight) house model (from blendswap).
  In model viewers: drag with left mouse button to rotate, middle mouse button to zoom, right mouse button to pan.
• Music maker. Uses WebGL and the Web Audio APIs to let you draw and perform music.
  Inspired by André Michelle's ToneMatrix and Karplus-Strong Guitar (see also wiki and this 2008 Linux Audio Conference paper), as well as DinahMoe's ToneCraft and the Tenori-on.
• Quake on XO-1.75 (video). Of course we need to actually run WebGL with good performance on XO hardware. Jon Nettleton has been working hard on our GL drivers, enabling the GPU on the XO-1.75 hardware for the first time. This Quake demo shows his progress—don't worry, Quake is not actually part of the Nell demo! (We have a GPU in the XO-1.5 as well, which hasn't yet been utilized.)
• Codify—not one of our demos (it's a commercial iPad app) but it demonstrates the direction we'd like to push Pippy.

Coming soon: TurtleArt and Implode for the web. We've started converting them to GTK3 in preparation for hoisting them bodily onto the interwebs. Here's the source code repository for the TurtleArt port if you'd like to watch or participate in this hackage. (See repl.it for one of the more unusual ways to get Python running in the web context.) The rest of the demo source code is on github (or just "View Source" in your browser).

Syndicated 2011-11-01 22:28:14 from Dr. C. Scott Ananian

Introducing Nell

Between now and January CES, Chris Ball and I will be building Nell for the OLPC XO-3 tablet. Nell is a name, not an acronym, but if you want to pronounce it as "Narrative Environment for Learning Learning," I won't stop you.

Nell's development will be demo-oriented—we're going to try to write the most interesting bits first and learn as we go—so don't be upset if you don't see support right away for legacy Sugar activities ("Sweet Nell"), robust sharing support, mesh networking, or whatever your favorite existing feature is. They'll come, but the new crazy stuff is what we need to evaluate first.

Here are four of the big ideas behind Nell, along with pointers to some of our sources of inspiration.

Narrative. I probably don't need to restate that Neil Stephenson's "The Diamond Age" has been hugely influential, and we also owe a large debt to interactive fiction and the Boston IF group in particular. (Check out the talks from our "Narrative Interfaces day" at OLPC.) Wide Ruled (conference paper) and Mark Riedl at Georgia Tech have demonstrated interesting approaches to story representation. I'm also looking forward to the results of the Experimental Game Play group's September Story Game competition.

Emotion. The Radiolab podcast "Talking To Machines" crystallized my thinking about emotionally-attractive environments. The discussion with Caleb Chung, the creator of Furby, is particularly apropos. Caleb's goal is to make things which kids want to "play with for a long time," and he contributes his three rules for creating things which "feel alive": it must (1) feel and show emotions, (2) be aware of itself and its environment, and (3) have behaviors which change over time. Furby's pursuit of these goals include expressive eyes and ears, crying when held upside down, reacting to loud noises, and gradually switching from Furbish to English for its utterances. A living thing emits a constant stream of little surprises. Expect to see Nell put the XO-3's microphone and accelerometer to good use.

Talking and Listening. The "Talking To Machines" podcast also discusses ELIZA and Cleverbot, which dovetails with my interest in the popular Speak activity for Sugar and related toys like Talking Tomcat for mobile phones. The key insight here is that a little bit of "cheap trick" AI can go a long way toward making a personable and engaging system. We want Nell to feel like a friend. Recent work by the Common Sense Computing Initiative at MIT's Media Lab shows how we can reset this on a sounder basis and use mostly-unstructured input to allow the system to grow and learn (creating "behaviors changing over time"). In particular, I'll cite ConceptNet for its database and practical NLP tools, and inspiration from "Empathy Buddy," "StoryFighter," and the other projects described in their Beating Common Sense paper. It's also worth noting that open source speech tools are good and getting better (the VoxForge site points to most of them); also interesting is this technique for matching a synthesized voice to that of the user.

Collecting, nurturing, and rewarding. Collector games such as Pocket Frogs and Flower Garden are sticky activities which encourage kids to come back to the device and continue working toward a goal over a long period of time. Memrise is educational software illustrating this technique: its users tend a garden of flowers by mastering a set of flash cards. Nell will incorporate the sticky aspects of such games, possibly also integrating the Mozilla Open Badges infrastructure into an achievement/reward system.

I hope this has given you a general sense of the direction of our Nell project. In future blog posts I'll drill down into implementation details, demonstration storyboards, and other more concrete facets of Nell.

Syndicated 2011-10-01 05:18:05 (Updated 2011-10-01 05:45:36) from Dr. C. Scott Ananian

Narrative Interfaces

One Laptop per Child creates student-centric learning experiences. Our current software stack, however, is somewhat "shallow". When you turn on the XO, all the content is immediately available but there is no path or guidance provided. Nothing suggests what you should try first, or indicates an order to progress through the activities provided. Everything is available, but there's no built-in journey. No plot. How can we improve this?

This Friday (June 17) at 2pm Eastern we're inviting some folks over to OLPC's new offices at the American Twine building to discuss Narrative Interfaces, as part of the proposed XO-3 software stack. Nick Montfort will give a short talk on Curveship, his model-based interactive fiction system, and Chris Ball will present some related recent hacking. Angela Chang will present her Tinkerbooks early-literacy platform, which allows kids to interactively change the written story on the page. And I'll discuss Neal Stephenson's novel The Diamond Age (a recap of a short talk I gave at EduJAM in Uruguay), and give concrete suggestions for how Diamond Age's Primer might influence the software architecture for the XO-3. (I might even reveal how to make software testing semantically indistinguishable from writing a game!) Chris Ball and I have also been collecting best-of-breed "comic books that teach you something" as examples of educational narrative; we'll pass those around and post a reading list after the event.

The real point of this meeting isn't the talks, per se, but the discussions to follow. We're trying to gather folks who know a lot more about this stuff than we do, in order to learn from them and be inspired. We don't have a lot of space, unfortunately, so I'm going to have to ask for RSVPs from those who wish to attend. If you're in the Boston area and feel like you have something to contribute (and especially if you have created/could create Creative Commons-licensed content for education), drop me a line at cscott at laptop dot org. Describing what you can contribute to the discussion will help break ties if space is inadequate.

We will also live-stream the meeting at ustream.tv/channel/cscottnet. Afterwards we'll post higher-quality video and a list of cited works. Thanks in advance to everyone who will participate, online and off!

UPDATE: video now up; see this writeup on Chris Ball's blog.

Syndicated 2011-06-15 21:27:50 (Updated 2011-06-18 05:12:14) from Dr. C. Scott Ananian

Small systems... and distributed ones

Today I stumbled across some very interesting projects by Nickolay Platonov which I'd like to discuss in an OLPC context.

I've been hacking away at TurtleScript fueled partly by a drive for minimalism: a small system is a learnable system. To that end, the language is based on Douglas Crockford's "Simplified JavaScript" (as recognized by this top-down operator precedence parser) which tries hard to include only JavaScript's "Good Parts". For example, the initial code for the TurtleScript system uses prototype inheritance (via Object.create) rather than classical class-style inheritance. In fact, the new operator isn't even included in the Simplified JavaScript/TurtleScript language.

In a discussion of TurtleScript Alan Kay mentioned, "It is very tricky to retain/maintain readability (so the first Smalltalk was also an extensible language not just semantically but syntactically)." And today I stumbled across the Joose library, which gives a very readable syntax for traditional class-based inheritance. It backs this up with a robust meta-object protocol, introspection, and lots of nice features borrowed from Perl 6, CLOS, and Smalltalk. The syntax ought to work fine with the limited tile set of TurtleScript, although I might have to add a tile for the new operator.

However, adding Joose raises some questions. Is the increase in readability worth the addition of such a large library to the system? What impact will this have on understanding problems and debugging? Is a return to class-based inheritance a positive change? (There have been arguments that the make-a-clone-and-change-it practice of prototype inheritance is easier to understand for new learners.) Can a larger overall system actually be easier to understand?

And once we're looking at libraries... Nickolay Platonov is now working on Syncler, based on the Bayou system. Unobstructive replication mechanisms would certainly make it easier to construct the sorts of collaborative applications we've wanted for Sugar. I have two concerns with Syncler's current state. First, the use of explicit continuation-passing style greatly impairs readability. The JavaScript yield keyword helps a lot when writing asynchronous code. (It's not supported by all JavaScript engines, but yield wouldn't be hard to add to TurtleScript.) Second, Syncler's event model uses explicit callbacks. I've been greatly impressed with the Flapjax event model (and its strongly-typed functional cousin). Both of these changes ought to make asynchronous code much more readable—and isn't that an important part of grokking a system?

Syndicated 2011-05-24 16:22:51 (Updated 2011-05-29 22:48:04) from Dr. C. Scott Ananian

Turtles All The Way Down

Inspired by Bert Freudenberg, Ian Piumarta, and Walter Bender, I started hacking on "Turtles All The Way Down" (aka TurtleScript) on the plane back from Uruguay. Now there's a nice rendering demo to show what a tile-based editor for JavaScript might look like, as well as a bytecode compiler and interpreter for the language. The bytecode instruction set is still too large; encouraged by Craig Chambers' work on SELF I think I ought to be able to replace all the unary and binary operators, conditional jumps, and slot selectors by a single mapof operator. I can put a better object model on the interpreter, too; I've written some notes on the matter.

The question is: does this really have educational value? "Turtles all the way down" is a great slogan, and a fine way to teach a graduate-level class on compiler technology, but I feel that the higher-level UI for tile-based program editing is the really useful thing for tablet computing. I'm a compiler geek and love the grungy underbelly of this stuff, but I keep reminding myself I should really be spending more time building a beautiful fluffy surface.

Syndicated 2011-05-20 06:06:15 from Dr. C. Scott Ananian

Next Steps for New Technologies

I've reached the end of the month. I've accomplished my Android and NativeClient-related goals, but didn't get the time to do as much mesh and python investigation as I'd wanted. Here are some ideas for next month's work. (Next week I'll be in Uruguay for EduJAM.)

GObject Introspection (Android or NaCl)

1. Start by porting libffi. An android port would be straightforward, but since libffi involves code generation (ARM, x86), this is going to require a bit of assembly magic and the new "JIT"/"shared library" support in the NaCl plugin.
2. Then port gobject-introspection. GObject-Introspection relies on libffi for its guts, but the hard part of this port will be refactoring g-i's build process, which is not cross-compilation friendly. Might need to rewrite some tools. If targeting NaCl, you might consider finishing the code allowing execution of unsandboxed NaCl binaries.
3. Turn gobject-introspection on its head: generate GIR and a C binding for the platform "native" interface. For NaCl, this would be a GObject-using C-level binding of the browser-native DOM; for Android, this would be a GIR binding of the native Android APIs. These bindings should be mostly automatically generated, since they will need to continue tracking successive native platform releases/HTML5 features.
4. Demos! Change browser DOM from Python, write native Android apps in Python. Add a gobject-introspection binding to cforth, then do the same from forth. (Forth might be a simpler place to start than Python. Or not.)

GTK (Android or NaCl)

1. Build on the cairo/pango port to proceed to a full GTK backend for Android/NaCl. These backends ought to be upstreamable. The NaCl port should be based on the broadway work: the cairo canvas would be drawn to more directly, but a lot of the mechanism which captures JavaScript events and translates them into the GTK event loop could probably be reused.
2. Demo: "Hello GTK world" in Android/NaCl.

Sugar partitioning.

Bring Sugar closer to being a true multi-language multi-library platform.

1. Refactor sugar modules (for example, sugar toolbar widget) as standalone C libraries. Basic idea is to embed Python and export a C API, while preserving as much of the code as possible. Python libraries now invoke this library via g-i-r instead of directly. The python embedding tool is probably a useful standalone product.
2. Rewrite "Hello, Sugar" activity in C (or vala), using #include for import and GObject inheritance instead of python inheritance. Use this as a guide to pull apart sugar into modules (as above) to make this code actually work as written.

Miscellanous topics

1. ChromeOS w/ touch support.

   Find an appropriate machine, do an installation, what are the roadblocks/rough spots? Can we install on XO-1.75 as a testbed?

2. TurtleArt as JavaScript viewer/editor.

   Revisit TurtleScript work, but skip over the time-consuming "construct an editor" step by reusing the (excellent) TurtleArt code.

3. Mesh: android olsrd frontend, build testbed, research 802.11 DCF issues.

Summary

There are four rough topics here; I might try to continue the breadth-first search by spending a week on each. It might be more satisfying to downselect two of these issues and spend two weeks on each.

Syndicated 2011-04-29 15:47:57 from C. Scott Ananian

Pango/Android -vs- Pango/NaCl

At the end of my Sugar/Android week, I had a simple Pango-on-Cairo demo running. This was built on a stack of ported libraries, including gettext, pixman, freetype, libxml2, fontconfig, and glib, as well as cairo and pango. You can run the demo yourself by sideloading pango-demo.apk onto your Android device (tested on a Motorola Xoom), and you can browse the source code to see what it entailed (here's the scariest part). (I was inspired by Akita Noek's android-cairo project, but I ended up reworking the build scheme and redoing most of the ports.)

It made sense to start my Sugar/NaCl investigation by porting the same demo application to Native Client. The same stack of ported libraries was involved, although it was easy to include more functionality in the Native Client ports, including threading and PNG/PS/PDF support in cairo. The source code is a fork from the upstream naclports project, and the process was generally much cleaner. (But see my previous post for some caveats regarding naclports.) If you're using Chrome 10 or 11, you can run the demo in your browser (follow the instructions on that page). The Wesnoth team has a parallel project which ported some of these libraries as well, but not in an upstreamable manner.

The demo app uses cairo to draw the background, an animated X, and some basic text in the center; it uses Pango's advanced international text support to draw properly-shaped Persian text in a circle around it. The center text is the "proper" bilingual Greek/Japanese written form of "pango"; the text around the edges is the Persian name of the internationalization library, "harfbuzz". Note that the Persian text is written right-to-left—and that I didn't put a full CJK font in the NaCl app, so the Japanese "go" character is missing. The Android port rebuilds the font cache at each startup, so it loads rather slowly; the NaCl port contains a prebuilt font cache so it starts more quickly.

Both ports took about two weeks. I blew my original schedule, partly due to the Patriot's day holiday, and partly because I'd given Android about a week's head start by tinkering on it before my original schedule post. The framerate of the demo is much better on NaCl (so fast that the edges of the animated X look choppy in the screenshot), but the hardware isn't easily comparable, so the comparison doesn't really tell us much. The porting effort was certainly more pleasant on NaCl, since newlib is a much more complete libc than Android's "Bionic"—but having gdb available made debugging on Android easier. (There is an unintegrated NaCl branch that integrates NaCl gdb in the browser, though!)

Much of the GNOME/POSIX library stack assumes access to a filesystem tree and does file-based configuration. In our demo application, fontconfig was the most culpable party: it wanted to load a configuration file describing font locations and naming, then to load the fonts themselves from the file system, and finally to write a cache file describing what it found back to the file system. Most ported software is going to want similar access—even if you store the user's own documents in a Journal, software still expects to find configuration, caches, and other data in a filesystem.

Android provides the POSIX filesystem APIs, but the filesystem an app can touch is segmented and sandboxed. As discussed previously, Android's Opaque Binary Blob feature may allow you to create a app-specific filesystem, but this doesn't let you share (for example) fonts and font configuration between activities. NaCl might eventually provide a similar unshared mechanism based on the HTML5 AppCache.

The preferred solution is more limited, but more flexible: no built-in filesystem APIs are used (or in NaCl's case, provided!) at all. Instead, you provide your own implementation of the POSIX file APIs (either via the --wrap linker indirection or through an appropriate backend to newlib/glibc/glib). For the NaCl demo app, I wrote a rather-elaborate in-memory filesystem --- only to find that an even-more-elaborate one already existed in naclports. But the longer-term solution uses message-passing (SRPC in NaCl, intents in Android) to implement these POSIX APIs. In Native Client, the implementation would be in browser-side JavaScript, which would then allow you to share parts of the filesystem tree between activities and/or map it into (cached) web-addressed resources. In either case, your application still sees the bog-standard POSIX API it expects.

More problematic are the networking APIs. Here Android provides a pretty standard socket library, while Native Client provides nothing at all. Using a browser-based implementation, as for the file APIs, will work fine for HTTP, WebSockets and even P2P via the HTML5 P2P APIs. But it's not clear that (for example) glib's elaborate asynchronous DNS name resolver implementation can (or should!) be implemented in a NaCl port.

In the end, the porting effort and abstraction shifts needed for Native Client and Android are roughly comparable. I expect Native Client will hold a strong edge in allowing close integration with web standards and web technologies. Android will probably continue to hold an edge in third-party application support and platform maturity.

Syndicated 2011-04-29 15:08:56 from C. Scott Ananian