Tip of the Iceberg

Category rants
I haven't had a good rant in a while, so I suppose I'm about due for one.

When I described my desire to transfer data across domains, Sean rightly pointed out that this must generally be done server-side: tell the server where the data is, let it collect it for you, then transfer it back to the client. Fair enough. There's just one small problem: the example provided uses CreateObject to pull the data via the Microsoft.XMLHTTP object. The XMLHTTP part I'm fine with; it's the Microsoft part that concerns me. Nothin' against Microsoft, of course... but little Billy doesn't play well with others.

To recap my goals with XIDED, they can be summed up into a single intention: to allow Domino developers to code their apps from any device with an Internet connection. Any device. The mobile version is a long-term goal, of course, but in the short term it'll at least allow those of you who only keep a Windows box around for running Domino Designer to finally give it a decent burial. In my case, I haven't switched over entirely to Linux yet, and don't really have any reasons for heading in the Mac direction, but those of you in either camp deserve an IDE that runs on your preferred OS, and darn it, I'm determined to provide one to you. The additional remote development opportunities and licensing agility will be yummy little side bonuses, but the primary focus is severing the inexplicable ties between an IBM product and their competitor's operating system.

Anyway...... most of the application's AJAXy goodness is going to be within a single domain: the server pulls a list of its databases, the developer chooses one, and the rest of the client-server interaction operates within that space until another database is selected. So all transmissions flow directly between the client and the server that hosts the application. The only exception is the upgrade process. As I mentioned before, I want to give developers the option to upgrade more seamlessly (or less seamfully?) than is typical for Domino apps. All of XIDED runs on the premise that design elements can be exported to and imported from XML, so a central server on my domain will serve up the XML representing new and modified design elements, and any customer should be able to pull that into their own copy, thereby upgrading with a single click. But that means that the data has to traverse multiple domains, and AJAX don't like that so much. So we're going server-side. So one piece of this will run on my server, so if I'm fine with running Windows, I'll run Windows. But the portion actually requesting the data has to run on the customer's server. And what do we do when we want to be absolutely certain that our code will run on any operating system? Duh, we use Java.

Oh. Crap. Java.

No, no, wait, let me explain. I like Java. I really, really do. It's neat. It's all structured and stuff. It can do nifty things LotusScript can't, like overloading methods, implementing interfaces, etc. It gives so much control over error handling. It's powerful. And so on and so forth. I could go on and on about what I like about Java.

But then again, why would I use a power drill when all I really need is a hole punch?

I rewrote one of the agents in HTTPUpgrade in Java, and it works across domains. Huzzah. But man, what a hassle. Considering Java's nifty little method overloading, there should be some kind of URLReader class out there that takes a String (oh, say, perhaps a URL) as its input and lets me output the resulting page to another String. But no. The best (documented) approach I could find was to construct a URL object from a String, pass that into a BufferedInputStream, then pass that into a DataInputStream, and finally, read that line by line. Only to be warned by the compiler that this approach has been deprecated. But it compiled. It works. So for now, I'll stick with that.

I recently got into a debate with a colleague about the merits of Java. His opinion seemed to be that, just because a language can do more, it must be "better". I beg to differ. A Swiss army knife can do a heck of a lot more than a spoon, but try eating peas with one. It can be done, of course. But who wants to stab one pea at a time with a miniature screwdriver?

"Oh, but look at everything this fancy little tool can do..."
"Piss off. I'm hungry, and it's faster to just use my spoon."

I know that's a dumb analogy, but the point is that humans tend to design tools based on the functions they're intended to perform. It's one of the few things that separate us from monkeys. And some of the tools we continue to use on a daily basis happen to be some of the oldest tools ever invented. In almost every case, each can only do one thing. But that tool performs its one function better than any we've since devised, so we keep it around.

One of the strongest selling points for using Domino as a development platform is that it allows us to choose - literally line by line - which tool is ideal for the task at hand. I recall an incident where I had to stifle a chuckle as I watched a programmer's mind implode when he glanced at the code of a single button in a Notes client app and realized it was simultaneously harnessing four distinct programming languages: LotusScript, NotesFormula, Java, and C. Why? Because in that context, each was better than the others at what that particular line of code was attempting to accomplish. And Domino lets us decide. So I know Java is "the future", but for the time being I'm not quite ready to dump the rest of the tools out of my toolbox.