jr conlin's ink stained banana

Sorry for the lack of posts, i've been introducing Anne Marie to Seattle. (Ok, myself as well.) All-in-all, it's been a better experience than i figured it would be, and i was reasonably positive about it.

i'm posting shots to flickr if you're one of those folks that likes looking at other people's vacation snaps, and the odd post to twitter if and when i can be bothered to do so.

Definitely would do business again w/ Seattle. A+++.

Lately, there's a great deal of push by folks to move data into clouds. One post i read recently talks about how that's the new business paradigm and how unless we adopt that, we're screwed. i'm not so sure. Well, let me explain myself at least.

i do believe that the future is in distributed architectures and collaboration over "baton" style work (e.g. Pass that document over to me when you're done. i want to add some stuff.) Those are all fantastic ways to make everything miscellaneous and whatever other modern 2.0 term you want to use. Except there's a significant problem. What happens when the cloud goes away?

A lot of folks think that your data is a lot like your money. If you have $40K in some account and the bank fails, you don't lose your money. That's because the FDIC ensures that while the actual assets your money was converted into may be about as worthwhile as the south pole ice machines your bank decided to invest in, you still have cash in pocket you can put into a (hopefully) better managed bank. Still, there are limits. FDIC has a maximum they're willing to cover per investor, and they don't cover every sort of investment that your bank may offer. (e.g. that $200K you had in the bank mutual fund that was paying back 40%? Gone.) Investment banking is a gamble, it's just that the level of risk is low enough that it's not a major concern.

Thing is, "cloud computing" is also a gamble. Your account could go away for any reason. The company hosting the service could go away. The company that the company providing the service depends on could go away. Any number of things can go boom and suddenly you are in the rather frightening position of staring up at a beautiful, cloudless digital sky. What's more, unlike the current Financial systems which have checks and assurances that you and your money are not easily parted without your knowledge and consent, there are NO checks and assurances for your data.

Not yet at least. i mean, just wait until a few major services go off line and the Digital Great Depression hits.

This is absolutely why i consider 'online' storage secondary, and even then, i don't store everything with one provider. i've got redundant data stores on multiple sites to ensure that when (not if) some service goes bye-bye, i'm not hosed.

i do believe that eventually there will be services out there that do provide this level of redundant clouding, most from open source. We've got Jabber which handles IM away from singular sources. We've got OpenAuth to handle account validation and access. What we really need now is a service that lets us do memcache like data fetches to the cloud from trusted, managed sources. (e.g. i remotely request Document.X, the service authenticates, fetches it from my home drive if it's not already in the cache, allows me to share and modify, then writes the changes back to the trusted source.) Figure some bright soul will configure git or subversion to do something like that (if they haven't already).

i like clouds. Really, i do.

i just think they're not the best thing to go building your castle on.

Continuing on lessons learned from building a Mozilla Plugin, let me continue with what you probably really want to do anyway, get to the damn window content.

Sure, having a little window that says "Hello World" may be nice and all, but it's not going to do anything really cool. No, for that, it'd be damn handy to get the contents of what's in the current browser. Except, which current browser do you mean?

For that matter, which window do you mean? You can have a browser anywhere, including in that little "Hello World" micro window, each with their own context. Well, turns out that (surprise) there are a number of ways to get the window you want.

First off, the FUEL way, since it's far cleaner than the other way.
var activeWindowDocument = Application.activeWindow.activeTab.document;
Like i said, far cleaner. The astute will note that there's a few telling elements to the above clean statement. The first being that while there's a Globally available Application, it has more than one .window beneath it. Good for you. The .windows property contains all of the browser windows available under Application, including any that might be squirreled away in an extension. (Ok, Application is globally defined for XUL apps, which include the default Firefox implementation and any extension you may be writing, but not any XPCOM modules you may be creating. If it's not available for whatever reason, you'll have to instantiate it from XPCOM via:
var Application = Components.classes["@mozilla.org/fuel/application;1"].getService(Components.interfaces.fuelIApplication);

It's also possible to walk the various tabs the user may have opened (or you've added) to get that content, and obviously, once you have activeWindowDocument, you've got full access to the DOM of whatever happens to be in that window. If you add a listener to the activeWindow:
Application.activeWindow.addEventListener('DOMContentLoaded',this.onPageRefresh);
onPageRefresh will get called after the DOM has finalized anytime a page is loaded, and since XUL applications run in protected space, you can make as many external calls back to your server as you like without asking for user permissions.

(Starting to feel paranoid about what extensions you load? Good. You should.)

The less clean manner is to take advantage of one of the older XUL globals and call getBrowser().contentWindow.document;. This instantiates and returns the global gBrowser which you can later refer to. Why is this less clean? Well for one, it's not really well documented, and considering that the Working with Windows in Chrome section offers the less than helpful way of getting the Application window:
var mainWindow = window.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
.getInterface(Components.interfaces.nsIWebNavigation)
.QueryInterface(Components.interfaces.nsIDocShellTreeItem)
.rootTreeItem
.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
.getInterface(Components.interfaces.nsIDOMWindow);
You'd be looking for shortcuts too.

A few additional notes:
The XML pretty-printer is exceptionally fickle. If you modify the content of the page in any manner, it will revert the page to plain text. It does this because it hates you.

To be honest, i'm using a combination of these approaches because i'm under the gun and learning. Eventually, i plan on cleaning things up to the point where i'm only doing things the right way, but that's not happening this week.

One of the reasons you've not heard much from me lately is because i've joined a monastery and devoted my attention to transcribing the Manhattan Yellow Pages into pages of hand written Urdu been spelunking into Firefox 3 in order to build out an extension.

The extension is, by and large, fairly simple. i can't really say the same thing about the Firefox docs, however.

i've been taking notes and have been thinking about releasing a "how-to" guide for building these things. Kind of a step above building a "hello world" type plug-in where you start doing more useful things.

The problem is, however, that engineers generally don't have time to write documentation. This is important to note because one of the things that's been most frustrating lately is the fact that once you try to dig into something, you inevitably fall down one or more rabbit holes of "nearly working solutions" that give "almost enough" info for you to work with. And then you discover that things recently changed and now it's much easier to do things.

Let's take debugging for instance:

The classic way one goes about dumping stuff to the Javascript Console according to the docs is to call dump(). That works, for the most part, except when it doesn't. There can be any number of reasons why (such as you're running inside of a protected chrome window and the local "window" object hasn't been created yet, or you've not enabled browser.dom.window.dump.enabled=true, etc., etc. and sadly, etc.). One of the outcomes is that the console buggers itself and stops showing any output at all. Digging around in the docs shows a slightly more direct way of getting to the javascript console by calling:
var console = Components.classes["@mozilla.org/consoleservice;1"].getService(Components.interfaces.nsIConsoleService);
console.logStringMessage(msg);
which does a damn reliable job of getting your string to the javascript console.

Well, unless you're running Firefox 3, in which case, you could call
Application.console.log(msg);

You probably don't know about that because it's part of FUEL, the brand, spakin' new library that makes writing extensions super easy. Granted, you probably have no idea that FUEL exists because it's not mentioned on the Mozilla Developer Home Page, although there are a veritable termite's nest of holes one can fall into right there.

The absolute One Thing i've found out is that the only way to really get how this stuff falls together is to crack open the browser.jar file in your Mozilla App/chrome directory and get spelunkin'. (A jar is just a renamed .zip file.)

So, what i'm going to do is keep notes here. i'll be posting up various things i've discovered while building out my plug-in and you can benefit from it. Consider this Mozilla 201, Slightly more advanced, but no where near doctorate level.

(Plus this'll give me a topic to ramble about.)

In the early 90's, the natural progression of all applications was to handle email (i believe this reached the apex when a few calculator programs offered to email their results to you.)

In the early 2000's the natural progression of all applications chanced to "becoming a language", and thus was born a thousand fragrant blossoms bloomed like so many open septic tanks upon the virtual landscape. This too changed and now every application wants to be a web client server possibly with some aspect living in the "cloud" of data ensuring that when your account on said "cloud" dissipates, you're screwed.

Of course, not to be outdone, the hardware industry is much the same, only instead of "email", "language" and "web client", feel free to substitute "mp3 player", "image gallery" and "phone". Possibly all three at once, along with the ability to handle email, have it's own scripting environment, be a web server and connect to some nebulous data repository system. (Thus probably explaining the overwhelming popularity of the iPhone.)

i bring these up mostly because whenever i'm deep in the throws of some gadgety lust, i always wonder about the amount of space i really need. As a f'rinstance, my car has a built in MP3 CD player, meaning that i can stuff 770MB of mp3s onto a chunk of plastic and have it play them. Figure that means i can put about 8 hours* of music on a single CD and have it play. (* figure that the average song is about three minutes, twenty seconds and i can stuff around 950 songs (~256kbps) into 1GB of memory.) That's enough to get me from San Jose to San Diego without repeating a track.

Not to be out-done, i've also got a GPS, which (it being a modern piece of equipment) can play up to 2GB of MP3s, which gets me about 18 hours of music, or to put it slightly differently, about a month of back and forth drives to work (provided i take the scenic route). Of course, i only usually listen to that when i forget to grab my 8GB mp3 player what can hold 72 hours of continuous music, or the Archos which can hold 30GB of mixed media (e.g. 7 full length movies plus 7+ hours of music) meaning that at the lower limit i'll be entertained continuously for something like 21 hours non-stop. Which might be appealing, but then so is things like sleeping, eating, and not driving off of steep cliffs.

Still, most of that insomniatic entertainment time is theoretical for me, mostly because i don't have that much entertainment i want to consume regularly.

i have just shy of 6GB of stored MP3 tracks on my media server. Of that, i'm willing to say that half are tracks that i'd not be terribly upset if they were lost in some magnetic decimation. (While i'm a fan of Crowded House, i'm not really a fan of "Hole in the River", with the 2GB mini-sd card i've got in there, i've got maybe half of it loaded with music, including more than a few "skip" tracks.

So when i hear about folks saying "wow, only 60GB of storage? i'm not sure i can fit everything on that." i boggle a bit. Actually, no, a helluva lot, really. Are folks really listening to all 540 hours of music on that, or are they carting around several hours worth of the siblings of "Revolution #9" just because the can? (i'd have nightmares of getting on a plane when the less choice tracks come up for random rotation and losing it somewhere 11,000 feet over Ohio.) Hell, what about the folks grabbing 320GB devices? Are they catching up on old episodes of McNeil Lehrer News Hour during the 120 days of continuous play?

Good Lord, people, if you're going to listen that long, start by listening to Groucho.