wmsy, the Widget Manifesting SYstem, figures out what widget to display by having widgets specify the constraints for situations in which they are applicable. (Yes, this is an outgrowth of an earlier life involving multiple dispatch.) Code that wants to bind an object into a widget provides the static, unchanging context/constraints at definition time and then presents the actual object to be bound at (surprise!) widget bind time.
This is realized by building a decision tree of sorts out of our pool of constraints. Logical inconsistencies are “avoided” by optionally specifying an explicit prioritization of attributes to split on, taking us much closer to (rather constrained) multiple dispatch. For efficiency, all those static constraints are used to perform partial traversal of the decision tree ahead of time so that the determination of which widget factory to use at bind time ideally only needs to evaluate the things that can actually vary.
When I conceived of this strategy, I asserted to myself that the complexity of understanding what goes wrong could be mitigated by providing a visualization / exploration tool for the built decision tree along with other Debug UI features. In software development this usually jinxes things, but I’m happy to say not in this specific case.
In any event, wmsy’s debug UI now has its first feature. A visualization of the current widget factory decision tree. Grey nodes are branch nodes, yellow nodes are check nodes (no branching, just verifying that all constraints that were not already checked by branch nodes are correct), and green nodes are result nodes. Nodes stroked in purple have a partial traversal pointing at them and the stroke width is a function of the number of such partials. The highly dashed labels for the (green) result nodes are the fully namespaced widget names. Future work will be to cause clicking on them to bring up details on the widget and/or jump to the widget source in-document using skywriter or in an external text editor (via extension).
The Debug UI can be accessed in any document using wmsy by bringing up your debugger console and typing “document.wmsyDebugUI()”. This triggers a dynamic load of the UI code (hooray RequireJS!) which then does its thing. Major props to the protovis visualization toolkit and its built-in partition layout that made creating the graph quite easy.
I got my first modern Android phone at the end of last week and I figured it would be a good idea to get over the activation energy hump so it’s easy to do incremental mozilla hacking on it. Thanks to a lot of work by other people, this turned out to be pretty easy. It would have been even easier if the Android emulator ran at anything remotely close to real time or if my Samsung Galaxy S Vibrant (Bell Canada model) running 2.1 did not have a habit of locking up all the time. (And this is before my code touched it, mind you. I’m half-hoping my device is a lemon. If anyone knows how to tell a lemon from lockups-as-usual, please let me know.)
The screenshot shows my Android device running the app. It’s a super trivial wmsy UI showing contacts from my address book pulled down from a weave server that were put there by Thunderbird.
Anywho, props to:
- Phonegap, the HTML/JS way to write mobile apps! Major awesome.
- weaveclient-chromium, a slightly bitrotted pure JS weave client by Philipp von Weitershausen / philikon (now of the mozilla weave/sync team) which built on the weaveweb project by Anant Narayanan and pure JS crypto work by the people mentioned in the README.
- weaver and weave-ext by Shane Caraveo, which make weave happily run in Thunderbird and have it propagate the contents of the address book.
- The Mozilla Weave/Firefox Sync team who made it easy and practical for software like Thunderbird to partake in the encrypted synchronization revolution.
- RequireJS, CommonJS loader to the stars.
The relevant repos for those interested, are:
- weaveclient-js: This is a fork of weaveclient-chromium that ditches the chromium bits, makes things CommonJS/Asynchronous Module Definition happy, and slightly factors out the encryption so that thunderbuddy can provide ‘native’ accelerated encryption support on android.
- thunderbuddy: The phonegap android app repo proper. The only really notable thing at this point is the custom Java class that implements and exposes faster ‘native’ encryption methods. (Thunderbuddy can also just be used as a webpage on any reasonably capable browser with good JS performance.)
It’s worth noting that the goal is not actually to perform contact synchronization with Android. There are already a ton of ways to synchronize your Thunderbird contacts with gmail and from there your phone. The goal is to let other interesting data and meta-data propagate. I just picked contacts for this example because Shane already had the data propagating.