JSON as a data binding

In my never ending question for the be-all, end-all cross-language data binding story, I've been thinking lately about JSON.

First, consider that SDO is an important part of IBM's SOA story; it's a or the story for sending data via SCA. Let's compare SDO and JSON, in terms of the Java interfaces.

SDO's DataObject interface looks something like this (see page 23 in the referenced PDF file). Actually, this is just a bit of it.

public interface DataObject extends Serializable { ... boolean getBoolean(String path); byte getByte(String path); char getChar(String path); double getDouble(String path); float getFloat(String path); int getInt(String path); ... }

Now let's compare to JSON's Java interface, and again, just a bit of it.

class JSONObject { java.lang.Object get(java.lang.String key) boolean getBoolean(java.lang.String key) double getDouble(java.lang.String key) int getInt(java.lang.String key) JSONArray getJSONArray(java.lang.String key) JSONObject getJSONObject(java.lang.String key) long getLong(java.lang.String key) java.lang.String getString(java.lang.String key) ... }

Look familiar? Now, sure, SDO has a lot more 'stuff' in it than JSONObject, like change tracking, but, really, I'm not interested in that stuff anyway. In any case, if SDO is good, and JSON smells like SDO, I guess it must be kinda good also.

Next, if I had to implement just one type of 'object' serialization in a server, obvious choices are XML and JSON. JSON is trivial for JavaScript code to eat, and any other language will require some library, but there are plenty available (scroll to the bottom), for free, as long as you don't use them for evil. With XML, everyone needs a library. Not so much of a problem that you need some extra library, because everyone has XML parsers in their language environment, but it's more code you have to write to get the data. If AJAXy web apps are a core piece of what you're doing, JSON may be what you want to make your client-side app code to be a little snappier.

Lastly, one of the things I always think about with data-to-xml bindings is whether fields/properties/etc should be rendered as attributes or child elements. Sometimes, you have no choice; if the field is 'complex', you will likely have to render as a child element. With a string-valued field, you got a tough choice. If the value is small, it feels better usually as an attribute; if it's longer, it feels better as a subelement.

None of this is an issue with JSON. Blissfully choice-challenged.

Sure, there's gotchas with JSON, like the fact that it really just models structs, lists, primitive types. Specifically, it has no way of handling classes. This is an issue when you want to serialize some data in JavaScript, and send it to a typed language, and would like to have that data turned into typed objects; instead of something like SDO's DataObject or JSON's JSONObject. No one wants to deal with that crap. The obvious sort of thing to do is have a magic field in your struct, named maybe "__type__" or something, that provided an indication of the class. This would of course be a pain to have to add manually in the JavaScript object, but if you could provide thin wrappers in JavaScript to poof objects like this up ....

So, I'm thinking it would be interesting to see what a JSON data binding story would look like. On the Java end, I'd want to deal with EMF objects, so the idea would be to serialize EMF objects using it's metadata, and when JSON is deserialized, somehow it gets turned into EMF objects. On the JavaScript end, code that generates these objects would be done with some kind of thin wrapper to add the magic field.

Eclipse Monkey

Ward and Bjorn have put out an interesting plugin for Eclipse called Eclipse Monkey. I bugged Ward after he joined Eclipse to please do something about the dearth of scriptability in Eclipse. This seems like the start of something interesting, but at the moment feels a bit too much like a toy.

It doesn't help that I have almost no experience in writing Eclipse UI plugins. Even the stuff the Find_System_Prints.em is doing is a bit over my head; in terms of what the 'doms' are doing, anyway.

Hanging Rock

Me and the boys went to Hanging Rock State Park today. Photoset available here. Great weather; about 60°, not too windy, a few clouds in the sky. Also, pretty much empty in terms of other visitors, and no leaves on the trees so you could see more.

Man, I was exhausted by the time we made it to the top. The kids seemed less so. I guess I really am getting old.

Which Javascript framework?u

So I've looked at least briefly at:

• Yahoo! User Interface library
• dojo
• MochiKit

Haven't looked at:

• script.aculo.us
• Prototype

Prolly won't look at, cause they involve flash:

• Zimbra
• Lazlo

But I dunno. You can do lots of pretty cool stuff with Flash. Even thought there might be a possibility of this stuff running on a PocketPC or something, I guess PDAs are soon to be dead, so the point there is kinda moot. Actually I took a quick peek at Zimbra late last year and realized they didn't really have a story for running outside of a JSP/Servlet environment. All of their component .js files got pulled in via a .jsp. Um. Ick. It's the new millenium guys.

Thoughts on the ones I've looked at:

dojo has a lot more stuff than yui and mochikit. dojo's documentation is quite thin, compared to the other two though. Besides just doc, or maybe just because of the doc, the other two seem more professional. But you know, there's no reason you couldn't use all of them at the same time. You would hope. In fact, I think I saw in the mochikit stuff some dojo-sniffing and -enablement.

Taking a look at MochiKit again right now. It's pretty slick.

Javascript evolution

I'd been thinking for a while now about writing some kind of JS app and making use of my .mac iDisk space via WebDAV. Should work fine with XmlHttpRequest. Why aren't more people doing this? I guess WebDAV is not that prevalent. Actually, an even more interesting story would be using SVN, since they support Autoversioning via WebDAV. Slick.

For iDisk anyway, Alex Young posted a blog comment a while back pointing out some Javascript files on idisk.mac.com that Apple uses to access iDisk itself from the web. There's somewhere to look for help anyway. WebDAV isn't, generally, that hard of a thing to deal with, although I've always run into odd little problems with it.

And, by the way, What the frick is that ZIP webdav method? hmmm.

So, imagine I have some nice utilities to access files. Files. What other operating system-ish capabilities could you imagine? Start simple and say you have a 'page' which is really a 'desktop'. You create a windowing system, allow folks to create new windows (floating divs?) with shell trimmings that the 'os' manages. A little app controls the content of the window. hmmm. Kind of like live.com, only a desktop, not a page.

In general, I think it's an interesting space to be in, to watch folks extend Javascript usage/capabilities, since the great Ajax hype started anyway. DOS 2.1 days. What's the Win 3.1 version going to look like? What's the Mac OS X version going to look like?

ws-success

he he

http://ws-success.pbwiki.com/FrontPage

Fixing my web site

I've been meaning to fix up my web site at http://homepage.mac.com/pmuellr/index.xml for a while now. Not really to fix the content, which I also need to do, but fix the structure. See, I use a little trick to get some of the common elements on each of the pages. The first hint is that the pages are xml files, not html files. But do a "view source" on one, and you'll start to see what's going on.

The real trick lies in the second line in the xml files.

<?xml-stylesheet type="text/xsl" href="local.xsl.xml"?>

I'm formatting these xml files with XSLT. It's my XSLT stylesheets that bring in the common header, footer, etc. I even used it to create 'new' tags like <url> that take the text inside an <url> / </url> pair, and render it as a link to itself.

Why do I want to change this? Seems like it works pretty good. It works quite well on Firefox Mozilla and IE. And doesn't work at all for me on Apple's Safari browser. Which is kind of embarassing since the site is hosted on Apple's .mac site.

The Safari problem, whatever it might be, is probably fixable. In fact, Safari just last year, late in the year IIRC, started claiming support for in-browser XSLT. Only, my site has never worked. Just comes up blank with no errors, warnings, nada. Some basic experiments led me to believe it was probably the sheer number of files I was pulling in to get one page loaded that probably did me in. Fixable.

But that's not the real reason to change this. XSLT, if you've never played with it, is pretty freaking inscrutable (inscrutable is one of my favorite words). Every time I decide to tweak something, I'm lost. The same way I felt after trying to tweak the first Perl program I wrote, a couple of weeks after I wrote it.

So I want to do something else, and of course I'd be nuts to not consider AJAX, since AJAX is so unbelievably kewl! Actually, I'm not building a fricken web app here, but a site, so AJAX isn't really what I want at all. But I do want a little piece of it, that being XHR (XmlHttpRequest). To be able to have the header and footer information available separately from the content, but weave it together when viewing a page.

My first thought was to go ahead and make it a web app, where I'd just have one page, and then mod the links on that page to do XHR requests to replace the body. There are a number of problems with that approach. One being that users wouldn't be able to navigate the site with forward/backward buttons. Another being that they couldn't bookmark pages. Of course, there are ways around these issues, but they're a little unnatural.

But then I realized another problem: Google does a terrible job of indexing xml pages. I had done a vanity google the other day, and just happened to think I didn't remember seeing any links to my home page. Just tried again a minute ago, and nothing really immediately came up for "pmuellr". So I helped Google a little, by asking for "pmuellr site:homepage.mac.com". And got three hits. One of them my resume in PDF. Two of the XML files got labelled "File Format: Unrecognized". Screw that. Guess I can't blame Google though. It's not real clear how I could tell Google "I swear a browser will render it as HTML". Which is kind of a lie, obviously, if your browser is Safari, or some other browser that doesn't support XSLT.

The only way to fix THAT problem is to provide the pages as HTML. So I think I'll start some experiments where I take the current pages, change 'em to HTML file extensions, and figure out the smallest bit of header info that I can use to get the header / menu / footer generated. And other stuff like the favicon, css, etc. Wonder if I should even bother trying to make it legal HTML, or if I just try using a script element at the top followed by the contents of the body underneath? Literally a one liner. I'm kind of a sucker for getting that sweet XML validation from editors though ... tough call ... tough call.

I'll post back when I know more, if I find some tasty recipe.

Java Funk

Not sure why this blog post showed up again, but it did, and it was another good read.

Maintainable Programmers from the blog lesscode.org.

What resonates most with me are the following nuggets:

• The implication appears to be that anyone in the real world, if only they’re using Java, writes well structured and maintainable code.

  I think the real world has a few surprises in store for people who think that way. As the saying goes, real programmers can write Fortran in any language.

• The overall design of large Java systems will tend to be more convoluted than that of almost any system written in a dynamic language, simply because the contortions forced by Java require larger overall designs.

  Java buries the intention of code under a thick layer of implementation details and typing bureaucracy. Programmers are drilled to execute the requisite gruntwork in repeatable, predictable ways. Moreover, doing so conditions them to design their own system to cater to these reflexes. A maintainance programmer who comes in later will therefore easily be able to make changes to the mortar of an application. Unfortunately, that does not ensure good high-level designs nor does it translate to easy refactoring of convoluted architecture.

  Dynamic languages abstract away huge swathes of gruntwork and require less structure. This means small systems have small implementations, which directly translates to better maintainability. The price is a loss of exemplary structure and of conditioning, which requires better innate architectural skills and stronger discipline when building larger designs; neither are strong points of the average programmer. However, designs in such languages aren’t frequently large, because the language does not require large architecture for modestly sized systems – which the majority are.

I've been in a serious funk over Java for the last six months or so (just a light funk for the last decade). It's been hard for me to explain to people why, since it's more of a gut feel thing to me, but this post definitely captures some of it.

XML Data Binding

With glee I read Tim Bray's WS-Angst post today. I really love to hate WS-*. Tim's post is chock full of great references, and a lot of those references have great references as well.

So one of the posts was complaining about xsd, and of course, what's not to complain about, but the poster said something about how XML-RPC was so much easier. hmmm ... I hadn't looked at XML-RPC in a while, thought I should take another look.

So I google it, and get here pretty quickly. The 'spec'. ummm, really? All these random references to it I've run across over the years, and that's it? I dunno, seems like unneccessarily wordy XML to me. At least there's no namespaces.

I've started a little effort to come up with a way to define an XML language that can be easily mapped into any programming language. An XML to programming language binding. Not related in any way to RPC, REST, etc. I think it's important to have a nice binding layer first; we aren't always sending crap over the wire. Figuring out how to do RPC with it is a later issue (although to be honest, that's actually simpler than the data binding; the SOAP element is 1/2 of it, defining a 'function call' in the request payload is the other 1/2). It's not rich; it's obviously not going to support every programming language feature known to man; nor will it support every variation of things you might want to do in XML. A Simple XML Schema language that generates easy to read and write XML, and can easily be mapped to any rational programming language available. It struck me as odd that there doesn't really exist such a beast, and it doesn't seem hard to create one, so I thought I'd get off my ass and do something interesting for a change.

On a somewhat related note, as I'm an IBMer, and a programmer, I'm of course forced to deal with EMF at work. It certainly seems like EMF's ECore would be a decent way to do this sort of thing, but it's actually more complicated than it needs to be; for example, I don't think in terms of a 'feature' aka attribute aka property aka instance variable being a fixed range of 'sizes', as you can do in EMF (you can define a feature saying it must have at least X items and at most Y items). I just think in terms of - it's a thing, or it's an open-ended list of things. Richer definitions of cardinality are kind of pointless. Or perhaps a way of expressing semantics, instead of syntax. Let's solve the syntax issue first, and layer semantics on top of that (if ever).

Cancelled trip to Charleston

Peter and I were planning on going to Charleston this last weekend; actually Sunday through Tuesday. But the weather foiled our plans. In two ways. First, the weather in Charleston, particularly on Monday, the only full day we'd be there, kept getting worse and worse every day we looked at it. But the weather in the triangle was the kicker. They were forecasting snow. I'd be a dead man if we were out of town and the triangle got snow. Since it would have been on the ground for all of an hour or so.

And of course, the weather in Charleston on Monday was cloudy and nice temp; and we never got any snow here.

I used Yahoo's Trip Planner again; it's not perfect, but it really is pretty useful. And the price is right. I should do a little review of it at some point. Anyway, we had planned on staying at the Doubletree right down town (on Market St, IIRC). Price wasn't horrible, and the location looked great. One odd thing was they wanted 48 hours advance notice for cancellation. That's kind of sucky.

So, we'll have to start planning another weekend. I'm not so sure about Charleston anymore though. The prices for staying downtown on a Saturday night are absolutely rediculous.