Tate on Continuations

Just read Bruce Tate's article Crossing borders: Continuations, Web development, and Java programming. I pretty much grok continuations; I definitely get the block concept ala Smalltalk, and once you get that, things like continuations don't look so unusual.

But here are some odd points that he made, at the bottom of the article:

New advances in Web development are rapidly making the continuations approach much more important. Rather than fetching whole Web pages with the traditional request/response models, Ajax applications can asynchronously fetch a small part of a Web page and weave the results into an existing page. But Ajax applications tend to force an application to maintain a connection to a user for long periods of time to keep applications responsive and keep state tracking easy to code. That practice defeats the purpose of stateless programming because you do need to hold resources for each connected user. With continuations, you can keep the state in a continuation and restore the state on demand.

I'm not sure that Bruce gets the whole Ajax thing. Ajax doesn't force any kind of connection as he suggests. The thing with Ajax is that you finally get to do client-side programming; keeping the state on the client, where it belongs. I have no idea what he's even trying to say here.

In the near future, hardware improvements will make the added resource consumption of continuations less critical. Without a major overhaul, Web development frameworks will still be too complicated. Ajax threatens to complicate Web development even more. These factors are all converging to drive the acceptance of continuation servers. In two years, most new Web development will use some continuation server or some simulation of continuations.

What hardware improvements are these? Hardware improvements that will make it cheaper to do continuations in Java? I doubt it; it seems to me there are few hardware changes that impact Java at all; it is a virtual machine, after all! I imagine he must be thinking about virtualization stuff that's coming. But I don't think the enhancements for virtualization are intended to scale to virtualizing our servers over thousands of users. But you never know; I used to use VM/CMS for development back in the day, and it in fact virtualized a 'machine' over hundreds of users. Still, isn't virtualizing a machine for a single web user a bit overkill?

w/r/t Ajax complexity: I know some folks who have recently switched from a traditional J2EE web app development story to an Ajax-based one, and from what I hear (and see, from the app), they are making a lot more headway in getting the app done than they were with the traditional tools. Is it complicated? It's different; not sure it's any less complicated than the traditional tools. It certainly appears to be much more productive.

In two years, I would be very suprised if most new web development is using continuations. Since I don't see a PHP version.

Jazz

At Eclipsecon, there was a BOF session where some collegues demoed the product that I'm working on at present: Jazz. Best blog post I've seen describing it is here. More later when I know what we can talk about.

YouOS

This site reminds me of this blog post. Must check out.

Scripting Eclipse

I see there's another EclipseMonkey user.

I've been doing my usual fumbling here. I've sketched out an EclipseMonkey-ish plugin on paper that is a little more along the lines of what I wanted to do; namely, never have to write any Java code. You know, I keep forgetting that to do that, I need to write some Java code. Well, I do enough of that at work, as far as I'm concerned. I keep meaning to spend some quality time with Ruby. So I looked into JRuby to see if that might be useful alternative to Rhino. Unfortunately, the doc is a bit skimpy when it comes to actually launching it, without going through BSF. It's not quite clear how you go about referencing other JRuby files via require or whatever.

I also ran into EclipseShell. Which looks interesting, but appears to only support ad-hoc running of scripts. Ad-hoc is great, but I really want to build scripts and hook them up to things, at a minumum, a menu like Eclipse Monkey

Then I happened to remember that I'm already doing some 'scripting' of Eclipse through some external tool launchers that run some python scripts. And I have RDT installed, so I could do this type of thing, but in Ruby, and with a 'native' launcher. Maybe that'll scratch the itch for a while.

trying del.icio.us again

It's been about 9 months since I posted a del.icio.us link, and I've been wanting to get back in the habit of doing this. What I have been doing is posting links to blog entries in my Bloglines 'blog'. But that doesn't feel right. del.icio.us feels better, I guess since it doesn't tie me to a blog reader, and has lots of spicy APIs to get the data back out again.

So, will try to dump all the stuff I've put in bloglines lately into del.icio.us, and then do some re-org, and see if it works for me.

Eclipse Monkey publishing

Thought I'd paste in one of my scripts using the publishing help Eclipse Monkey supports. Just to try it out. You may be wondering what the wacky heading and trailing are all about. They are eclipse flavored lines from Jabberwocky. And they are easy to find in Google.

You'll want to grab the alert.js file from here.

--- Came wiffling through the eclipsey wood ---
/*
 * Menu: test > alert
 * DOM: http://homepage.mac.com/pmuellr/projects/eclipsemonkey-scriptloader/update/org.muellerware.eclipsemonkey.dom.scriptloader
 */

alert = ScriptLoader.loadProjectFile("MyEclipseMonkeyScripts", "monkey/lib/alert.js")

function main() {

 alert("Hello, World!")
}

--- And burbled as it ran! ---

update - 2006/03/20 - added title (keep forgetting that!) and added a link to the alert.js post

ScriptLoader available

I finished up my ScriptLoader Eclipse Monkey DOM last night. Spent more time building the freaking plugin, feature, site.xml, etc than on the actual code. But once all the feature stuff working, it is pretty nice. If you're interested in my vanilla Ant script that does this, look for the project source zip on the web site. Although my feature only has one plugin, I think this could scale to a multi-plugin feature if you were willing to have the feature and all the plugins at the same version number every time.

I also put the lamo web page for it (link above) in Eclipse as a help document. It's nice to have simple examples of doing this, like the eclipsemonkey plugin did. Thanks!

Something really bad happened while I was editing the HTML page, at one point. I lost the source some how. Deleted it accidently or something. I've never figured out the local editing stuff in Eclipse, or never seen it work in action, so I figured all was lost. A bummer too, because there was at least 1/2 hour worth of typing in there. But, I did have the page open in a web browser with the full content. hmmmm. Clearly I could cut-paste the code into a text editor and redo all the formatting. Or maybe paste into Word and try to recover from whatever bad HTML it would have generated. Then I remembered a little note on a blog I saw last week. Someone wanted to get the source for their page easily, and they had a little javascript: url you could plop in the address bar that would show you the source. Something like a document.innherHTML or something. Tried it and it didn't work, but then I thought I should try it in the JavaScript Shell, which is a really nice little bookmarklet thingamajigee. Brought it up, and after a few tries, found that document.body.parentNode.innerHTML got me exactly what I needed, except the HTML elements at the beginning and end. Swipe, copy, paste back into Eclipse. And it was a single, hugely long line. Sigh. I didn't have time to figure out if pasting somewhere else (Word or a text editor) might have left the line delimiters intact, so I decided to re-layout by hand. But boy was I glad I could at least get all the text + markup saved.

I'm starting to work on some little utilities with Eclipse Monkey + ScriptLoader. Experiencing what I have before in losing the one nice bene of overly strict typing in Java: code assist. Based on some of the snippets I've been typing, it seems to me like some static and flow analysis could yield pretty good typing information, given all the Java glorp I'm actually doing in JavaScript. Can't imagine anyone ever doing this though, and I'm not interested enough to do it myself.

First thing I'm going to try to build is a EM script to toggle showing unchanged (in the team sense) projects in the navigator. I really hate it when I have changes to commit across multiple projects, which are widely separated visually. I'd like to have a 'working set' which was programmatically defined: 'projects that are dirty in the team sense'. And be able to toggle that on and off easily.

Lots of stuff to learn.

Dash Time

I called into the Dash Time conference today. It was Bjorn and Ward and a little later, Wayne Beaton. And me. I don't think anyone else joined.

I completed hogged all the time chatting about Eclipse Monkey. What luxury to get these guy's ears for a little while. Wayne gave me an idea on how to fix my classloader issue with my scriptloader DOM, and I've got a hack in for it. Think I'll go ahead and package up what I got, to give me a chance to figure out how to create a freaking update site again (it's been two years since I've done this), and write some doc. I'll upload to my web site when I have something, but until bug 131360 is available in an Eclipse Monkey release, using ScriptLoader will also require a hack to the eclipsemonkey plugin MANIFEST.MF to export the javascript packages.

More Eclipse Monkeying

Playing with Eclipse Monkey

I spent a little time playing more with Eclipse Monkey yeserday. I've written a little Domain Object Model (DOM) that allows you to load and execute a JavaScript file. The idea is to create some little reusable functions / classes. The first quick test was writing an alert() function. Here's the source of alert.js:

//------------------------------------------------------------------- // a port of web browser's alert() function //------------------------------------------------------------------- alert = function (message) { Packages.org.eclipse.jface.dialogs.MessageDialog.openInformation( window.getShell(), "Eclipse Monkey Alert", message ) } alert

What's going on here is that I'm defining a function that puts up a dialog with some message in it. The last line of the file references the function, and ends up being the 'result' of executing the script with my DOM. Let's show the example that uses this in the file alertTest.em:

/* * Menu: Test > alert * DOM: http://localhost/org.muellerware.eclipsemonkey.dom.scriptloader */ alert = ScriptLoader.loadProjectFile("ScriptLoader Sample", "monkey/alert.js") function main() { alert("Hello, World") }

Taking it from the top, the Menu: line will cause a "Test" menu to be created under the Monkey Script menu on the main window, and then add a menu item to that called "alert".

The DOM: line points to my DOM. I cheated; the 'value' of the line is supposed to be a URL to the update site to get the DOM. The last path segment in the URL names the bundle the DOM is implemented in. As long as that bundle is loaded, the previous part of the URL isn't used for anything.

The next line with the alert assignment loads the script defined previously. Since that script 'returns' a function, we store the function in a variable called 'alert'. Note that the uses of alert in both files is completely independent. The name used in the alert.js file is basically thrown away. The only thing remembered in that script is the 'return' value. After the assignment from the result of the loadProjectFile() method, we can use the alert() function anywhere else in the .em file.

Pretty cool.

My next thought was to create a Console class which provided access to an Eclipse console. I thought this would be a nice way to support some basic println() capabilties. And would be pretty simple to test.

Here's the source for my Console.js class:

Array = java.lang.reflect.Array ConsolePlugin = Packages.org.eclipse.ui.console.ConsolePlugin MessageConsole = Packages.org.eclipse.ui.console.MessageConsole MessageConsoleStream = Packages.org.eclipse.ui.console.MessageConsoleStream //------------------------------------------------------------------- function Console(name) { var console = new MessageConsole(name, null) this.messageConsole = console this.messageStream = console.newMessageStream() var consoles = Array.newInstance(MessageConsole, 1) consoles[0] = console ConsolePlugin.getDefault().getConsoleManager().addConsoles(consoles) } //------------------------------------------------------------------- Console.prototype.print = function(string) { this.messageStream.print("" + string) } //------------------------------------------------------------------- Console.prototype.println = function(string) { this.messageStream.println("" + string) } //------------------------------------------------------------------- Console.prototype.println = function() { this.messageStream.println("" + string) } //------------------------------------------------------------------- Console

And here's the tester:

/* * Menu: Test > Console * DOM: http://download.eclipse.org/technology/dash/update/org.muellerware.eclipsemonkey.dom.scriptloader */ alert = ScriptLoader.loadProjectFile("ScriptLoader Sample", "monkey/alert.js"); function main() { var Console = ScriptLoader.loadProjectFile("ScriptLoader Sample", "monkey/Console.js") console = new Console("testing, 1, 2, 3") alert(console) console.print("1") console.print("2") console.print("3") console.println() console.println("1") console.println("2") console.println("3") }

Bad news. Looks like I'm unable to load the MessageConsole class. As near as I can tell, the issue is that while running an Eclipse Monkey script, you only have access to stuff that the plugin that runs the script has visibility to. That plugin is org.eclipse.eclipsemonkey. You can change this, to some extent, with your own DOM, as it can see whatever it wants. However, that doesn't help in the JavaScript code, only in the Java code that implements your DOM.

Dang. The whole reason for doing my scriptloader thing was to try to radically cut down on the amount of Java you would need to write interesting scripts. I can see we are limited by strict classloading rules the eclipse runtime lays down on us. Which you can 'relax' by writing your own plugins. Which kills the idea of radically cutting down the amount of Java you need to write.

Sigh.

Web Services != Distributed Objects

I got a chance to talk to Arthur Ryman last month, for a few minutes, so took full advantage of the situation and launched into a rant/whine on WSDL. I gave him a brief synopsis of what we're trying to do on the project I'm working on (can't talk about it right now, sorry), and he made an interesting statement. "You're trying to use Web Services to do Distributed Objects. You should think in terms of document exchange instead." Not an exact quote, but pretty close.

I've been thinking about that a lot lately.

He's right, and he's wrong. We are/were trying to do distributed objects, and I really should know better than to even think about this. I've done CORBA ORB implementations, and worked on IBM's VisualAge Distributed Smalltalk project. Been there, done that, know it's a freaking mess. Even when you get it technically working, it becomes difficult to disentangle your object mess with your distribution mess. I've never seen it work well. So, he's right in that we shouldn't be doing distributed objects.

Where I think he's wrong is that we have to think in terms of documents. If you're doing nothing but storing documents, I guess it's fine. But really, we got clients wanting to talk to servers and presumably they want to send data back. Not documents. Then I have to map a document to data and back. Ick. Especially when the 'spec' way to do this is with the unbelievably horrible xsi spec (sorry Dave, I'm not smart enough for this stuff, or maybe I'm too old).

That's why JSON intrigues me. Data. Yummy, yummy, data. And really, I think you could take a view of Web Services using XML as a problem looking for a solution. There are few languages where mucking with DOMs is in any sense fun. I even had a chance to play with REXML last night, and, while I can write some pretty compact code to do interesting stuff, I still need to understand either DOM or XPath to do it. XPATH is another one of those things that's almost too hard. I can remember the easy bits, but then always need to go back to the inscrutable spec to get my work done. Ick.

Another interesing use case for the JSON stuff is returning arbitrary SQL result sets over the wire. If you want to XML-ize this, in such a way that you can easily WSDL it up, and have programming language bindings that are at all usable, you end up with a story where you have something like an SDO that wraps all your objects. And then the XML looks like crap, and just adds more overhead. The answer: remove the strict typing requirement!