Last year Databinder interfaced with Ruby for text processing, using XML-RPC because it seemed like the easiest option. The project ran years late and millions of dollars over budget.

Just kidding—it went fine of course. (And Databinder nets a cool zero million no matter which way the wind blows.) Using a scripting language in an external runtime for text processing, and caching the results, has been an unmitigated success. This is why probably no one else in Java is doing it. They would rather use those what you see is the tip of an ugly iceberg editors and warehouse a bunch of disgusting HTML generated by Microsoft Word. (This happens by way of the clipboard.)

But! Smart people prefer REST over XML-RPC. It’s true. Anything that abstracts remote procedure calls over HTTP is bad according to them, even things less obviously torturous than SOAP. Maybe they’re right. It’s definitely true that you don’t need XML to represent the single input and output strings of this chore, nor the abstraction of remote procedure calls.

Some parts of the REST creed are unappealing. Basically everything starting with the word “always.” And Wicket as a web framework is the anti-REST. So, there’s that. But unlike actual religion, with programming religions you can pick the parts you like and use them without being burned at the stake. At least not physically.

The part about REST that rules is just getting stuff done with the world’s de facto standard of software communication whenever feasible. Databinder’s simple problem, shuttling markup strings between the JVM and Ruby runtime, can be directly handled by HTTP. To use any other protocol, or layer something on top of this one, is just silly.

Old databinder-dispatch was a Java library depending on some XML-RPC libs that themselves depended on HttpClient. New databinder-dispatch dumps those other libs and also (why not?) is written in Scala. Um,

Dispatch is the first Databinder module to be rewritten in Scala. Last June this weblog brashly pro­claimed its hope to rewrite the entire toolkit in Scala. Plans change though! Instead of porting the now-plural persistence modules, it makes more sense to factor out IModel using first class functions. A page would acquire needed values, some how, and bind them to components as by-name parameters.

val post_method = new PostMethod(server_base + path_name)
post_method.setParameter("input", source.toString())
post_method.setRequestHeader(
 "Content-Type", "application/x-www-form-urlencoded; charset=utf-8")

(new HttpClient).executeMethod(post_method) match {
  case 200 => ()
  case code => error("Bad response code: " + code)
}
val out = post_method.getResponseBodyAsString()

So basically it’s posting some UTF-8 text to an endpoint defined externally. And on the Ruby side:

srv = HTTPServer.new( :Port => 8180 )
def create_server(srv, name, &convert)
  srv.mount_proc('/' + name) do |req, resp|
    require name
    resp.body = convert.call(req.query['input'])
    resp['Content-Type'] = 'text/html; charset=utf-8'
  end
end

The only annoying thing here is having to verbosely specify UTF-8 all over the place. But if you don’t do that, and then roll out to some environment that defaults to the evil Latin-1, forget about your em dashes and curved quotes surviving a round trip. The Ruby side doesn’t seem to pay much attention to the encoding either way, but HttpClient needs to know on both ends that it’s UTF-8 or it will assume whatever the JVM’s default is. (It would be nice if there were a terse way to set a local default when instantiating the HttpClient!) (It would be nice if WEBrick echoed whatever content type encoding header came in!)

Later: The trunk code is using HttpClient 4 inside a Scala wrapper (inherited, not implied), that changes the client’s default to UTF-8.

All told, the HTTP-only code was not any harder to write than the original XML-RPC code was. (For more extensive Scala REST coding it would be worth writing a few implicit wrappers for HttpClient.) The two can’t be compared line to line, since the Java became Scala and the Ruby has become a fuller-fledged init.d service, but feel free to poke around:

• XmlRpcLabel.java
• databinder-dispatch.rb — XML-RPC
• HttpPostConverter.scala
• databinder-dispatch.rb — HTTP

And of course there are some pre-fab components set up to use the HttpConverter that entirely abstract out the remote business. The old version had a base XmlRpcLabel and a pile of subclasses in separate source files because in Java you have no choice. The new version just has the HTTP converter and puts all the text format classes (which are mostly one-liners anyway) in a single TextFormattedLabel source file.

The top-level Scala components like TextileLabel can be as easily accessed from Java as regular Java classes. But working with the format signifiers—if you need to select a format at runtime—is trickier, because they are singleton objects like Textile$.MODULE$. But it does work.

Next week let’s rewrite this in SOAP for another comparison! Just kidding that would suck.