Spontaneously Combusting

Mauied 25 Years

More Maui pics
 

Notes/Domino R8 Beta Now!

Get it  here.

A few *hundred* shots from Italy

Slideshow

More soon

Update: Tons more pics

levitz

This is a qiuck take on a simple client for viewing couchdb databases and documents. The features and installation instructions are in the readme file. More info and a new version in a few weeks.

Download levitz_0.1.1

It's a trap!

M. David Peterson theorizes that competitivness is behind MSFTs offer to help mozzila.org port Firefox to Vista:

"..MSFT doesn’t like to be outdone by ANYONE.."

Hmm, that doesn't explain the last five years. My theory: they want to lure the FF developers up to Redmond in the winter and dampen thier spirits in the cold, grey, rain so the IE team can catch up. That'll give the IE folks time to implement Javascript 1.7, more CSS, native svg and xaml. And they can steal e4(x)linq from the vb.net folks while they're at it ;-)

XMLHttpRequest(..., returntype=<DOM | e4x | SAX | javascript | ?>)

Given that Firefox implements e4x and SAX (SAX is chrome:// only), and given that these could be useful for processing XMLHttpRequest responses, and given that it doesn't make sense to build a DOM and then convert to an e4x object or a SAX stream, I would like to pass a return type of DOM|e4x|SAX|javascript|??? to the XMLHttpRequest and just write an appropriate response handler. Is that too much to ask?

e4x<-->DOM

To clarify the e4x example, here is what I would expect form the forthcoming?(slide 5) e4x/DOM integration (see Jeremy's comment):

function writeList(domDoc){
    var xdoc = new XML(domDoc);
    var xlist = <ol/>;
    for each (label in xdoc..label){
        xlist.* += <li>{label.name.text() + ' (' + label.@id + ')'}</li>;
    }
    document.getElementById('updateTarget').appendChild(xlist);
}

DOM 2 e4x

I've been following Uche Ogbuji's Javascript in Firefox series on Developerworks. It sounds like e4x will be in the next article. I can't wait. Here's the javascript form the "labels" example using e4x instead of DOM. Compare this javascript to Listing 2 in the article:

function loadAddresses(){
    var doc = document.implementation.createDocument("", "", null);
    doc.onload = function(){writeList(doc);};
    doc.load("labels.xml");
}

function writeList(domDoc){
    var xdoc = new XML((new XMLSerializer()).serailzeToString(domDoc.documentElement));
    var xlist = <ol/>;
    for each (label in xdoc..label){
        xlist.* += <li>{label.name.text() + ' (' + label.@id + ')'}</li>;
    }
    document.getElementById('updateTarget').innerHTML = xlist;
}

Gates[1] = 'Ray Ozzie'

One has to wonder if he's a one hit wonder. Notes was a hit (stay with me here). Groove by comparison was not. He will be the new top architect (visionary) at MS. That 's good for MS overall but with Notes, Ray had the vision and built the product.

assert(Ozzie[1] == 'Damien Katz')

Noteskinnable

Jonvon asks for a skinnable Hannover.

I'd like to see skinnability solved at the RCP level. CSS for SWT. Or perhaps one of the java XUL implementations for SWT. UI builders would generate the XML + CSS . You could manipulate it on the fly with XML APIs. Hmm...this is starting to sound exactly like the Mozilla platform. But it could work for Eclipse RCP-based UIs too. I absoultely agree that a highly configurable UI would do wonders for Notes applications. Keep all the Notes-ness in the background. Like a well-written Domino App. The question is how much of the RCP UI can us developers get at in Hannover?  Or does composite applications only mean WCT as as Notes shell.