pmuellr is Patrick Mueller

other pmuellr thangs: home page, twitter, flickr, github

Saturday, August 18, 2007

response to jsr 311

Marc Hadley responded quite quickly to my blog entry on JSR 311. Excellent. I'm really digging the transparency. I'm thinking Twitter may have played a part in the quick response.

w/r/t the GPL vs CDDL licensing issue; sorry, I'm sure I saw CDDL on some of the pages, I should have included it in the blog post. I frankly am not all that familiar with the CDDL, but Dave Johnson got me curious about something, and sure enough, it looks like Apache allows CDDL licensed binary software to be shipped with Apache projects. Note that the link above is a proposal, but it sounds like Apache is already doing this in some cases with CDDL. Very cool.

As for the other issues Marc raised; it's silly to debate via blog posts; looks like the would be the most appropriate place to have the discussion.

But I can't resist making two notes.

From Marc: "On the Java ME side, the fact that 311 is primarily a server side API ... means it is less suitable for the ME environment anyway."

To quote from the Java ME Sun Products overview, "As CDC is not limited to just the wireless market, and expands into other emerging markets like digital television, telematics, multi-function printers, ...". Those sound like platforms that could make use of a server supporting RESTful web services.

From Marc: "Jersey will automatically produce a WADL description"

Wonderful. The point isn't even necessarily that you should make this part of the spec, but to ensure that this is do-able within the current spec's design. Because you don't want to find out later, after the spec has been finalized, that the design prevents something like generating a description. Sounds like you're doing that with the WADL generation. I'd like to see the same done with the client.

Friday, August 17, 2007

on JSR 311

Some thoughts on JSR 311 - JAX-RS: The Java™ API for RESTful Web Services. The description of the JSR, from the web page is: "This JSR will develop an API for providing support for RESTful (Representational State Transfer) Web Services in the Java Platform."

Here are a few related links:

Some of the positive aspects of the ongoing effort:

  • It's good to be thinking about some facility to help people with RESTful services, in Java.

  • This JSR seems to be much, much more transparent than most JSRs; published meeting minutes (though a bit skimpy), mailing lists, reference implementation work being done in the open, etc. Wonderful. Wonderful!

  • Even the current drafts of the spec are available, on-line, without a soul-sucking click-through license agreement! The most recent one is the "Editors draft - July 3rd, 2007 (PDF)".

  • The general approach as currently implemented / described by Jersey feels more or less right. Of course, I say that because I've been recently looking at doing something similar, without having seen JSR 311, and there's a lot of commonality between the road I was heading down, and the one JSR 311 is going down. Use of annotations to augment methods and classes which describe the services, specifically. Some of the annotations I had come up with were in fact the exact same names that Jersey uses!

OK, now for the bad news.

  • The licensing for the open source side only accommodates the GPL half of the universe. Leaving folks wanting something more like a BSD style license, to fend for themselves. Of course, that's not necessarily bad, it's always useful to have some competition. But it's also nice to have a single common implementation that everyone can use. There are many licenses that would be compatible with the GPL and acceptable to a wider audience.

  • Specific issues from the 2007/07/03 spec draft: Section 1.2 Non-Goals:

    • Support for Java versions prior to J2SE 5.0: The API will make extensive use of annotations and will require J2SE 5.0 or later.

      Read: Sorry, J2ME. Sorry, folks stuck on Java 1.4.

    • Description, registration and discovery: The specification will neither define nor require any service description, registration or discovery capability.

      Read: We'll figure this out later; hopefully we won't have to change anything in this spec once we start thinking about this aspect of the problem.

    • Client APIs: The specification will not define client-side APIs. Other specifications are expected to provide such functionality.

      Read: We'll figure this out later; hopefully we won't have to change anything in this spec once we start thinking about this aspect of the problem.

The licensing issue is bad enough that it's really going to force an alternate implementation to be developed. This might be something that Apache would typically do, but given the Apache / Sun disagreement on JCP issues, it's not really clear to me that Apache will ever be interested in working on JSR implementations again.

Another interesting wrench to throw into the gears is Eclipse. As of Eclipse 3.3, the Equinox project has been shipping Jetty, along with some goop to allow you to use OSGi within servlets, or start an HTTP server as an OSGi service. Adding RESTful service support to this story seems like a logical next step to me. Note that the existing JSR 311 non-goal of support for <= Java 5 support violates an OSGi constraint of running in their smaller (1.4.x-ish) environments.

Seems to me, if we're going to have to work on an alternate implementation anyway (to solve the licensing issues), we might as well solve some of the technical problems as well (J2ME / Java 1.4 support, service descriptions, client apis, etc).

And yes, I do know of RESTlet™ but have not looked at it extensively; the licensing and Joint Copyright Agreement and trademark issues are non-starters for me. It is also on a pathway towards becoming a JSR.

Anyone up for a "Battle of the RESTful frameworks"?

Sunday, August 12, 2007

Ruby Hoedown, day 2

Saturday was day 2 of the Ruby Hoedown 2007. I had to leave early and so missed "Using C to Tune Your Ruby (or Rails) Application" by Jared Richardson, and the final keynote by Marcel Molina, Jr.

Nathaniel Talbott, one of the conference organizers, mentioned before one of the sessions that the sessions are being recorded, audio and video, along with the slides presented, and will be available on the web shortly. With some kind of a Creative Commons license. Wow! I wish more conferences did that. I won't dive into details on the sessions below, since the info will be available soon, verbatim.

Sessions I did attend:

  • Building Games with Ruby - Andrea O.K. Wright

    Andrea discussed a handful of gaming toolkits for Ruby. Supporting everything from MUDs to 3D. A few of the toolkits were wrappers over SDL.

  • Lightning talks

    • test/spec - Clinton Nixon - layers an RSpec-inspired interface on top of Test::Unit
    • a strategy game written in JRuby, using Swing - didn't get the presenter's name
    • methodphitamine - Jay Phillips - a more powerful alternative to Symbol#to_proc
    • Ruleby - Joe Kutner - a pure Ruby rule engine
    • tyrant - Patrick Reagan - a way to run Rails applications without each user needing a development environment
    • generating Ruby classes - Luke Kanies - dynamic code gen
    • Iron Ruby - Brian Hitney - Ruby implemented on the CLR
    • static sites with Rails - Brian Adkins - how to enable mostly static pages with Rails
    • Thoughtworks test strategies - Dan Manges - how TW designs tests for teams
    • myDecisionHelper - Tyler Start (sp?) - self-help web app

  • BOFs over lunch

    Went to Rick Denatale's "Smalltalk for Rubyists; Ruby for Smalltalkers". More the former than the latter, unfortunately for me. But still interesting and informative.

  • Does Ruby Have a Chasm to Cross? - Ken Auer

    Great talk; like Bruce Tate's keynote on Friday, referenced the book "Crossing the Chasm" (just added it to my 'wanna read' list). Ken's talk came at it from a different angle: being there, when Smalltalk was just about to 'cross the chasm', but didn't make it. Why didn't it? What can we learn from Smalltalk's tragic history?

All in all, great conference. I'll be there next year, assuming they have it again. Maybe I'll have some more Ruby under my belt by then.

Forgot to mention in the previous post that I used my Nintendo DS-Lite with the Opera browser, again, to do some lite surfing, email checking, twittering, during the conference. Very convenient.