Blogging Roller

Lots of latest links: social networking APIs and more

Dave Johnson — Mon, 4 Feb 2008 14:00:07 +0000

First, some links from open source projects I'm trying to follow. Check out the JMaki Webtop widget, it looks pretty useful. Now that I've got JMaki support in Roller, this could be the basis for some cool drag-and-drop blog layout. Wish I had time for that; I'm still trying to carve out some time to dig into the Abdera server framework.

jMaki Webtop
Cool iGoogle style portal interface via JMaki
JSPWiki: JSP Wiki 3 Design
JCR back-end, wiki spaces and more...
Abdera Server Implementation Guide
"The Abdera Server module provides a framework for constructing Atom Publishing Protocol server implementations."

I'm also following OpenSocial and Shindig (the reference implementation of OpenSocial) pretty closely, but thus far have not had time to dive into the code. There's lots of activity on the Shindig list, but thus far there's no server-side and security is still up in the air -- both are pending change to the spec itself. Marc Cantor has an interesting perspective on the OpenSocial.

ShindigStarted - hyves_api - Trac
"a small guide on how to get started on Shindig."
CNET Mark Cantor: Waiting for the OpenSocial hammer to drop
"We all hope that MySpace, Bebo, and others will open up and go beyond the original scope of OpenSocial to lay the groundwork for a truly open world of social networking."
<a href="http://www.techcrunch.com/2008/01/17/kickapps-publishes-api-kit-adopts-facebook-and-opensocial-platform- standards/">KickApps Publishes API, Adopts Facebook and OpenSocial standards
"KickApps has adopted Googleâ€™s OpenSocial developer platform standards and is working with Facebook to adopt that companyâ€™s standards as well."

I'm also following Facebook. While Google and friends scramble to catch up, Facebook Apps are getting easier to write, thanks to a new JavaScript API, and easier to deploy thanks to Amazon Web Services.

Facebook Extends Platform to the Web - The Unofficial Facebook Blog
"This is a huge step in Facebook extending their platform beyond the Facebook.com domain and letting people leverage the power of the social graph"
JavaScript Client Library - Facebook Developers Wiki
"Applications that use this client library should be configured to load in an iframe, not be rendered with FBML"
Facebook JavaScript Client Library
"This JavaScript client library allows you to make Facebook API calls from any web site and makes it easy to create Ajax Facebook applications"
Amazon Web Services Blog: AWS For Facebook Applications
"we've teamed with Facebook to collect all of the resources that you need to be the next big success story in one convenient location."

Personally, I really like the idea of the web itself as the social network and your blog as the home for your personal profile. So, I think the new Social Graph API is a step in the right direction, as is the blog-based Distributed Social Networking (DiSo) project.

BuzzMachine:The internet is the social network
"The internet doesnâ€™t need more social networks. The internet is the social network."
Social Graph API - Google Code
Project homepage
Google Social Graph API Released on Dion Almaer's Blog
"Would you like to be able to make a quick call to get a JSON response that ties together a social graph made up of resources available on the Web?";
diso - Google Code
"DiSo (dee â€¢ zoh) is an umbrella project [for] as Chris puts it: 'to build a social network with its skin inside out'"
The Existential DiSo Interview on Vimeo
Factory Joe interviews himself re: Distributed Social Networking

And, I'm happy to see support for Twitter-like microblogging in Wordpress and Facebook like activity streams from Movable Type.

Introducing Prologue: WordPress.com
"Weâ€™re fans of Twitter around here, [but] while the format appealed to us it really just whetted our appetite for something more"
Building Action Streams - MovableType.org
"framework for collecting your actions from services around the web into one place for you to share back out as you see fit."
Action Streams | Plugin Directory | movabletype.org
"aggregate, control, and share your actions around the web "

And to wrap up: maybe I don't need to worry about the intersection of Blogging and Social Networking at all. Maybe there's no need to following all these APIs. Maybe the hype has peaked and Facebook and friends are about to go the way of the CB radio. Apparently, folks aren't spending quite as much time Facebooking as they used to:

ZDNet.com: Ohmigod! Social networkers just canâ€™t take it any more!
"it is entirely possible that people are beginning to question just how much time they spend socially networking, rather than socially living."

Latest links Nov. 12, 2007: Glassfish, OpenSocial and more

Dave Johnson — Mon, 12 Nov 2007 07:23:08 +0000

Sound Opinions from Chicago Public Radio and American Public Media
Best podcast ever

The Aquarium: GlassFish Interim Governance Board - Now Complete
"The complete roster is Tony, Greg Luck (Wotif.com) and Pierre Delisle (Google), and Simon and myself (Sun)"
Bistro!: GlassFish/SJS AS in production - which bundle, which profile, ...?
Explains differences between developer, cluster and enterprise profiles
GlassFish Podcast: The GlassFish Podcast
Finally, a Glassfish podcast! Props to Alexis Moussine-Pouchkine
Apple - Downloads - UNIX & Open Source - GlassFish
Download Glassfish V2 directly from Apple
Red Hat and Sun Collaborate to Advance Open Source Java Technology
"Red Hat has signed Sun's broad contributor agreement that covers participation in all Sun-led open source projects."

Megginson: First looks at OpenSocial: part 1 (URLs)
Lists the URIs for the AtomPub collections available in OpenSocial
Megginson: First looks at OpenSocial: part 2 (members and friends)
How OpenSocial members and friends are represented in Atom format
Megginson: First looks at OpenSocial: part 3 (activities)
How OpenSocial activities are represented in Atom format and manipulated via AtomPub protocol
Megginson: First looks at OpenSocial: part 4 (persistence data)
How OpenSocial persistence is implemented via AtomPub protocol
Google: OpenSocial Container Sample
Shows "basic demonstration-level OpenSocial container can be implemented"
Dare Obasanjo: OpenSocial Tech. Overview and Critique
"Despite these misgivings, I think this is a step in the right direction. Web widget and social graph APIs need to be standardized across the Web."

snellspace.com: Notes, Part 2
"lots and lots of things that can be modeled as collections of web resources"
netzooid: Building Services with AtomPub
"While APP is not the one true protocol, I think I?m hooked"

Blogapps 2.1 released

Dave Johnson — Tue, 2 Oct 2007 21:49:40 +0000

<a href= "http://www.amazon.com/dp/1932394494?tag=bloggingrolle-20&link_code=as3&creativeASIN=1932394494&creative=373489&camp=211189"> The next releases that I'd like to announce are the Blogapps 2.1 Examples and the Blogapps 2.1 Server.

If you'd like to learn more about the Blogapps examples and server then read The Blogapps Project article at Java.net. Here's a quick summary:

The Blogapps project hosts a collection of useful RSS and Atom utilities and examples from RSS and Atom In Action by Dave Johnson. They're designed to be useful even if you haven't read the book and they're available under the Apache License 2.0 so you can use the code in your applications and you can modify and redistribute them as you wish.

What's changed since 2.0? The examples have been updated to include the latest version of ROME Propono, which means that most of them now support the final Atom protcol spec. The server has been updated to include Roller 4.0 RC5, which also includes Atom protocol support and JSPWiki 2.4. And of course, various bugs have been fixed. Here are the release files, installation instructions and release notes.

This blog entry was posted via Atom protocol and the MatisseBlogger blog-client, which you can see in the screen-shot below (which was also posted via Atom.

What's next? Not sure at this point, but I will do another Blogapps release once ROME 1.0 is released.

Atom Protocol Exerciser (Ape) setup notes

Dave Johnson — Thu, 28 Jun 2007 20:23:06 +0000

UPDATE: things have changed quite a bit since I published this blog entry. There is now a Ruby Gem for installing Ape and the process is much easier than the one I describe here. See Sam Ruby's post Migratory Ape for details - Dave (March 1, 2008)

There's some very cool Atom news from Tim Bray this week. First, there's mod_atom, a plugin for the Apache HTTPD web server that provides a stripped down Atom server (written in C) that stores Atom entries as files. So now any HTTPD server can serve as a simple Atom store.

Second, Tim mentioned that he's updated his Atom Protocol Exerciser (Ape) to support the new Atom protocol namespace and to add a couple of new tests. That's perfect timing for me because I'm starting to work on Roller's APP implementation and some other APP based things.

I need my own local copy of the Ape, so I decided to download the code an get it up and running. To make things easy, I decided to do this work on my Ubuntu system because it's already setup with gcc, cvs, Apache HTTPD and Ruby. For my future reference and to help other Atom fans to get started, here are my notes from my Ape setup experience.

Setting up the latest Ruby#

Tim told me that the Ape needs Ruby 1.8.6, but Ubuntu has only 1.8.4 and apt-get upgrade ruby didn't help so I downloaded and built 1.8.6 myself. Here's what I did:

% wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6.tar.gz
% tar xzvf ruby-1.8.6.tar.gz
% cd ruby-1.8.6
% ./configure
% make
% sudo make install

Once the make install finished, I found that I had a fresh new copy of Ruby in /usr/local. Next, I set up my environment for running Ruby by adding the following three lines to my .bashrc file.

export RUBY_HOME=/usr/local
export RUBYLIB=$RUBY_HOME/lib/ruby:$PREFIX/lib/site_ruby/1.8
PATH=$RUBY_HOME/bin:$PATH

Setting up the latest RubyGems and Builder#

But that's not all the Ruby you need for the Ape, you also need some RubyGems so I downloaded and built the latest version of that too. I followed nearly the same steps as with Ruby:

% wget http://rubyforge.org/frs/download.php/20989/rubygems-0.9.4.tgz
% tar xzvf rubygems-0.9.4.tgz
% cd rubygems-0.9.4
% ./configure
% make
% sudo make install

Next, I setup environment for running RubyGems by adding GEM_HOME to my .bashrc. I did this by adding the following line after the definition of RUBY_HOME.

export GEM_HOME=$RUBY_HOME/lib/ruby/gems/1.8

Ape needs the RubyGems Builder, so I ran this command to get the latest version of the Builder from the RubyGems repository:

% sudo gem install builder

Downloading Ape#

Finally, I've got enough Ruby in place to get going. So next I got the latest source for the Ape. Unfortunately, I think you need a Java.net account for this part. Here's what I did:

% cd /home/dave/src.downloads
% cvs -d :pserver:snoopdave@cvs.dev.java.net:/cvs login
% cvs -d :pserver:snoopdave@cvs.dev.java.net:/cvs checkout ape

Setting up an HTTPD ScriptAlias for running the Ape #

Next, I created a ScriptAlias so I can run the Ape via CGI. I did this by adding the following to the end of my Apache config file (/etc/apache2/apache2.conf on Ubuntu):

ScriptAlias /apecgi/ /home/dave/src.downloads/ape/src/
<Directory /home/dave/src.downloads/ape/src/>
   Options +ExecCGI
</Directory>

The Ape scripts don't the have the #!/path/to/ruby line that you'd expect to find in a CGI script, so initially I couldn't figure out how to get them to run. I pinged Tim and he told me that he uses a bash CGI script to run the Ape's entry-point go.rb script. Following Tim's example, I created a file named "go" in the Ape src directory with the following contents:

#!/bin/bash
export RUBY_HOME=/usr/local
export GEM_HOME=$RUBY_HOME/lib/ruby/gems/1.8 
export RUBYLIB=$RUBY_HOME/lib/ruby:$PREFIX/lib/site_ruby/1.8
PATH=$RUBY_HOME/bin:$PATH
export PATH
ruby go.rb

Putting the Ape HTML form in place#

So the Ape code is in place and ready to run, but I still need to serve Ape's HTML form. I decided to serve the form from HTTPD docroot, so I created a directory for it mkdir /var/www/ape. Then I went looking for the HTML form. Turns out, it's not in CVS. So I browsed to http://tbray.org/ape and used Firefox's "Save Page As..." and "Web Page, complete" to save index.html. Then I copied that index.html file into /var/www/ape and modified the action to point to /apecgi/go.

And off we go...#

Finally, I restarted Apache via sudo apache2ctl restart, browsed to http://localhost/ape and found Ape there, ready to roll.

That was a lot more complicated that I had expected; makes me wonder if I'm the first person (other than Tim, of course) to deploy the Ape.

Joe's Q&A: Do we need WADL?

Dave Johnson — Tue, 5 Jun 2007 17:57:22 +0000

Joe turns a #redmonk IRC chat-room discussion into an insightful Steven O'Grady style Q&A on REST, WADL, interfaces and APP. For the record, I still think WADL is going to be useful to many, but I think APP is going to be a whole lot more useful and it doesn't need or use WADL.

Update: Pat Meuller has more on the WADL question. Apparently, there were some interesting hallway discussions about about out at IBM RTP. I just caught the tail-end of that on IRC.

Friday Atom and REST links

Dave Johnson — Fri, 25 May 2007 22:30:40 +0000

A bunch of Atom and REST related links that I came across while catching up with my blog reading today:

Atom and LDAP sitting in a tree. Trey Drake has released his OpenDS based Atom store as an open source project on Java.net at http://atom.dev.java.net. It's a directory server distributed as a Java web application that supports both Atom Publishing Protocol (APP) and Lightweight Directory Access Protocol (LDAP).

Signing, encrypting and decrypting Atom. On IBM developerWorks, Nicolas Chase explains how "digital signatures and encryption can easily mesh with Atom data using the Apache Abdera API."

Google GData: A Uniform Web API for All Google Services. Dare Obasanjo praises Google for creating a single uniform and RESTful web services API for eight of its key services, the APP based GData API. He writes "not only is it now possible to create a single library that knows how to talk to all of Google's existing and future Web services since they all use GData. It is also a lot easier to provide 'tooling' for these services than it would be for Yahoo's family of Web services given that they use a simple and uniform interface."

RESTful web services support in Netbeans. Geertjan links to blog entries and a screen-cast that explain Netbeans 6.0 support for RESTful web services, including the early access JSR-311 REST API.

Generate code from your WADL REST API. Eduardo at The Aquarium links to Thomas Steiner who is making progress on a WADL editor and a generator, bringing WSDL-like code generation to RESTful web services.

The Apache Lucene GData server project

Dave Johnson — Tue, 15 May 2007 22:18:21 +0000

German Viscuso: Generally spoken GData provides a general interface to make information available even beyond a browser context by providing a single API that could be used to query, update, and index structured data anywhere on the web. Could GData become a simple and open replacement for all the proprietary communications protocols currently in use by database vendors?

Interesting thoughts. I've heard about the Atom Publishing Protocol (APP) based Lucene Web Services API, but I hadn't heard about the Apache Lucene GData server project. Atom protocol is moving fast, especially considering the fact that it's not finished.

APP and OpenID at JavaOne

Dave Johnson — Mon, 7 May 2007 14:43:56 +0000

Trey Drake: How do you demo a directory server? Build cool apps around it. To that end, we've built an Atom/APP server, a lightweight OpenID server, a blogging and "twitter" like app - all powered by OpenDS. Drop by our booth (Glassfish alley at CommunityONE and .org section of the pavilion during JavaONE). Ludo and I will introduce OpenDS and show off the demos in two talks; today at CommunityONE at 5PM and Wednesday at 1:30 in the CommunityCorner.

Very cool. I'm not going to be the only one talking about Atom protocol at JavaOne. I'll have to stop by the CommunityCorner, that sounds too good to miss.

APP interop follow-up

Dave Johnson — Sun, 22 Apr 2007 19:59:19 +0000

Following up on the APP interop event last week, here are the ROME Propono APP client issues we found:

And here are the Roller APP server issues:

I plan on fixing the Roller issues for this summer's Roller 4.0 release. I won't have time to fix the Propono issues for the upcoming Propono 0.5 release (due this week), so they'll be in 0.6 sometime after JavaOne.

WSO2 Web Services Mashup Server

Dave Johnson — Wed, 18 Apr 2007 01:17:17 +0000

I was wondering what web services vendor WSO2 was doing at the APP interop event. Turns out, they've got a "Web Services Mashup Server" in the works.

APP interop event day #2

Dave Johnson — Wed, 18 Apr 2007 01:16:33 +0000

The Atom Publishing Protocol interop event is over and now I'm catching up on blogs and email in my hotel room in Mountain View, CA. In the end, I was able to run ROME Propono successfully against Blogger/GData, AOL Journals and Wordpress. I also found a dozen small problems in Propono and in the Roller APP server.

For more information on the event, check O'Reilly's Keith Fahlgren's summary of the event titled Atom Publishing Protocol a Success. Keith mentions that "big industry players like AOL, Google, IBM, Microsoft, Oracle, and Sun are working on APP clients and servers and sent people to the interop event with interesting code" and I agree that's definitely a good sign for the protocol.

I thought it was particularly interesting that database vendors IBM and Oracle showed up with DB2 and Oracle-backed Atom stores. If Google's half-dozen or so Atom protocol based services aren't enough make you stand up and take notice, surely that should get your attention.

APP interop event day #1

Dave Johnson — Tue, 17 Apr 2007 10:24:47 +0000

Day one of the Atom Publishing Protocol (APP) interop event was a success, at least from my point-of-view. I was able to test the Propono client against Blogger.com/GData, AOL Journals and an implementation from Oracle. I found and fixed problems in Roller's APP implementation. Plus, it was great to meet all of the good folks implementing Atom and to get a close look at the Google campus. I'm getting ready to drive back to Google now so... gotta go.

Check out Tim Bray's blog for some photos of the event.

ROME Propono 0.4 released

Dave Johnson — Tue, 10 Apr 2007 15:20:26 +0000

I'm happy to announce the first release of the ROME subproject Propono. Propono is a ROME-based Java class library that supports publishing protocols, specifically the Atom Publishing Protocol and the legacy MetaWeblog API. Propono includes an Atom client library, an Atom server framework and a Blog client that supports both Atom protocol and the MetaWeblog API.

Here's the project page
http://wiki.java.net/bin/view/Javawsxml/RomePropono

Here's the Propono 0.4 release page:
http://wiki.java.net/bin/view/Javawsxml/RomeProponoRelease04

And here's a link to the API docs, which include details, diagrams and code examples:
https://rome.dev.java.net/apidocs/subprojects/propono/0.4/overview-summary.html

I'll be testing Propono this week and next (at the Google-hosted APP interop meeting) so now is a great time to provide feedback and bug reports. I plan on releasing Propono 0.5 in the *very* near future.

Atom protocol interop event

Dave Johnson — Thu, 5 Apr 2007 17:16:06 +0000

I just got approval to attend the Atom protocol interop event at Google April 16 and 17. I'll be bringing at least three Atom protocol implementations: Roller's Atom server, Propono's simple file-based Atom server and Propono's Atom client.

Atom protocol as the substrate for reliable messaging

Dave Johnson — Thu, 5 Apr 2007 16:48:03 +0000

I've heard the argument before that the REST approach to web services doesn't give you reliable messaging and that's the reason you need to stick with WS-*. Today Bill de hÃ“ra disputes that notion with an interesting and somewhat provocative post that mentions a couple of specs for messaging via HTTP (HTTPLR and BTF) and argues that Atom protocol can serve as the basis for web-scale reliable messaging.

Bill de hÃ“ra: There are a number of reasons to choose Atom Protocol as the substrate for web-scale reliable messaging. First, a ton of software will be written to target APP in the next few years, and there is plenty of scope for extending the protocol; this suggests openly available and flexible software stacks. Second, since all document collections in Atom Protocol are served as Atom Feeds, it has inherent support for systems management and end to end reconciliation. Third, Atom entries have identity and are natural envelopes, unlike SOAP, where identity and true enveloping requires further specification (essentially raw Atom presents a better basis for interoperation than raw SOAP). Fourth, Atom Protocol can support binary content transmission not just XML, and thus can transmit arbitrary payloads. Finally, because Atom Protocol respects media types and deployed HTTP infrastructure, independent proxy inspection and security check-pointing can be installed cleanly, also eliminating the need to rewrite 2 stack layers and buy XML appliances to support and secure SOAP backed web services. It seems to be a question of when, rather than if, this will get built out.

I would have blogged about this earlier today, but Bill's blog looked foobar and I didn't realize that today is CSS Naked Day. My blog doesn't look half bad naked.

Latest links: March 21, 2007

Dave Johnson — Wed, 21 Mar 2007 22:42:13 +0000

David Van Couvering: Why use Atom Publishing Protocol for REST?
"Why not just use HTTP and JSON and have done with it?"
Max Ross: Ode to Hibernate (and Shards)
"Shards, a framework that adds support for horizontal partitioning (or in Google parlance, "sharding") to Hibernate Core"
James Snell: Don't Panic
"it is possible to get very far with nothing but the base APP protocol."
Elias Torres: Is AtomPP for or not for blogs?
"we'll probably have to do some good amount of extra work in defining how blogging clients will interact with a blogging service"
Rob Yates: Atom Publishing Protocol - not enough for blogs?
Rob wants a guide that "allows blogging clients to be interoperable with blogging servers"
Re: I-D ACTION:draft-ietf-atompub-protocol-14.txt
Roy Fielding: "the sky is not falling, and AtomPP implementations will interoperate just fine"

Atom protocol powered Blogging Portlet

Dave Johnson — Mon, 12 Feb 2007 23:17:17 +0000

Jeffrey Blattman has put together a new Portlet that makes it possible to blog via Atom Publishing Protocol (APP) from a portal page. He's added it to the Open Source Portlet Repository on Java.net so you can try it out against your favorite APP server.

APP interop at E-Tech

Dave Johnson — Mon, 29 Jan 2007 23:42:10 +0000

James Snell brings news of an Atom Publishing Protocol (APP) interop event to occur in March at the O'Reilly E-Tech conference. I'd love to use that as an excuse to go to to E-Tech, since my current work involves APP in ROME and Roller, but it sounds like I can participate remotely.

New Atom protocol spec draft and Queen City planets

Dave Johnson — Wed, 27 Dec 2006 16:50:19 +0000

Joe Gregorio announces a new Atom Publishing Protocol Spec (draft #12) and he says it might end up being the final. I guess it's time for a new Blogapps release with APP draft #12 and ROME 0.9 support.

Plus, Joe has put together a set of new planet sites for towns in the Charlotte, NC area; all based on feeds from Google Base, Google Blogs, Google News, Craigs List, Flickr and the Weather Service. The sites look useful, but the ads combined with the minimalist design make them look a little spammy on first glance. Perhaps a short "about this site" paragraph is in order.

Atom Publishing Protocol, draft #10

Dave Johnson — Wed, 13 Sep 2006 10:33:01 +0000

APP draft #10 is available. I'm still reading it over, but the major changes appear to be:

Categories can be specified at the ~~workspace and~~ collection level. Multiple category schemes are allowed and both fixed and free-form categories (e.g. tags) are allowed.
Collection titles are now specified by an <atom:title> instead of an attribute on the <collection> element.
A new "slug" header has been added for media posts so that clients can specify the file-name to be used for the uploaded file.

I'm especially happy about the category support -- now Atom protocol can do everything that MetaWeblog API can do, and much more. I'll be updating my client and server implementations during the next week.

Tri-XML 2006 presentation

Dave Johnson — Sat, 29 Jul 2006 12:12:20 +0000

Here's the abstract of the talk I gave this morning at Tri-XML 2006:

Beyond blogging: Atom format and protocol. Like XML-RPC and SOAP before, feeds and publishing protocols were born in the blogopshere and quickly moved beyond blogging. Nowadays, web service providers are using RSS/Atom feeds and REST-based publishing protocols as lightweight alternatives to SOAP. And developers are finding new ways to combine web services from different sites into new applications, known as "mash-ups" in the lingo of Web 2.0. If you'd like to do the same, then attend this talk to learn about the new IETF Atom feed format (RFC-4287) and the soon-to-be-finalized Atom protocol, which together form a strong foundation for REST-based web services development.

Here's a rough outline of the talk:

Introduction

Beyond blogging
Blogs hit the hit time
The web is bloggy
Atom as an alternative to WS-*

Understanding feeds

Birth of RSS
RSS 1.0: the RDF fork
The simple fork and RSS 2.0
Atom: the standard

Parsing feeds

Fetching and parsing feeds
Universal Feed Parser
ROME utilities
Windows RSS platform

Serving feeds

Approaches for generating and serving feeds
Feed autodiscovery
Styled feeds

Atom protocol

Compared to MetaWeblog
REST based approach
Introspection
Collections
Extending Atom

Atom protocol in action

Getting a service doc
Getting collections
Posting an entry
Posting an image

Demo: interacting with an Atom server via command-line

And here are the slides: TriXML2006-BeyondBlogging.pdf

Tags: topic:[Atom Publishing Protocol], topic:[Atom], topic:[APP], topic:[RSS], topic:[feeds]

Atom protocol and WADL

Dave Johnson — Fri, 28 Apr 2006 16:47:44 +0000

Via The Aquarium I see that Mark Hadley's work on Web Application Description Language (WADL) is now a Sun Technical Report. WADL provides a way to describe a REST based web application or service so that tools can discover services, generate proxies, etc. As I understand it, WADL is to REST as WSDL is to SOAP.

There's also something new since the last time I looked at WADL. Mark has added a section on the Atom protocol and examples that show how to use a WADL file to replace an Atom introspection document. Looks like good stuff to me. If you need an introspection doc for your REST based web service, why not use WADL?

Via Google, I found that there's also a WADL presentation on-line.

Pebble and Blojsom and Atom protocol

Dave Johnson — Fri, 3 Mar 2006 09:31:00 +0000

I've used code from the excellent Pebble and Blojsom blog servers in the past (and given credit in the Roller CREDITS file). I'd love to be able to contribute back and now there's an opportunity to do that. So to Simon and David (or anybody else hacking those servers), if you want to get Atom protocol working in your server, the easiest way might be for you to bring in some code from Roller. I specifically designed our Atom protocol implementation to allow for sharing and to be free of Roller dependencies.

For example, here's how you'd do it for Pebble:

Bring the classes from the package org.roller.presentation.atomapi into Pebble (except for RollerAtomHandler, you won't need that one).
You'll also need to bring in the ROME and JDOM jars if you're not aleady using them.
Implement the interface AtomHandler with calls to the Pebble backend, call it PebbleAtomHandler or something similar.
Change one line of code in the AtomServlet method createAtomRequestHandler() to create your new PebbleAtomHandler instead of the Roller one.

And feel free to pepper me with questions along the way. I'd be happy to help and happy to make changes to make this sharing easier. I'm also considering the idea of an Atom Server Kit package in my Blogapps project (on second thought, ROME might be a better home).

When you're done, head over to the #atom channel on irc.freenode.net so we can do some interop testing with MatisseBlogger and other Atom protocol clients.

Atom protocol, OpenSearch and Microformats

Dave Johnson — Fri, 24 Feb 2006 11:00:23 +0000

Joe Gregorio: APP, OpenSearch and Microformats. Get used to seeing them; those small pieces loosely joined are the future of web services.

Joe's talking about the new Lucene Web Services API, which is based on Atom protocol (APP), OpenSearch and Microformats. It's very cool to see the APP already applied outside of the realm of blogs.

Atom protocol draft 7

Dave Johnson — Mon, 2 Jan 2006 10:41:23 +0000

I was planning on submitting Chapter 8 of RSS and Atom in Action to Manning today, but Atom protocol draft 7 has appeared. The changes look good and the only really significant one for me is the move from list templates, which allowed indexing into a collection, to next/previous paging as we had in draft 4. I'm going to revise my implementation, Chapter 8 and turn it in on Wednesday. Once that's done, I'll release Blogapps v0.1.

Atom Protocol draft 05

Dave Johnson — Wed, 12 Oct 2005 18:27:45 +0000

There's a new draft of the Atom Protocol available and I've already started working on updating my client (the BlogClient example from my upcoming book RSS and Atom in Action) and server (in the Roller sandbox) implementations. Surprisingly, the new spec doesn't look all that different from the previous one, so perhaps a weekend of work will do the trick.

How Atom Publishing Protocol works

Dave Johnson — Fri, 3 Jun 2005 11:00:14 +0000

Unlike the other RSS and Atom books that are hitting the shelves these days, RSS and Atom in Action is going to cover the Atom Publishing Protocol. So, I'm following the protocol development very closely. This blog entry is a summary of Atom as it stands today (based on Draft 04 released May 10, 2005). It's a follow up to my post earlier post Atom in a nutshell which explained Atom API 0.9.

Atom Publishing Protocol (a work in progress) is a new web services protocol for interacting with a blog, wiki or other type of content management system by simply sending XML over HTTP, no SOAP or XML-RPC required. Your code interacts with collections of web resources by using HTTP verbs GET, POST, PUT and DELETE as they are meant to be used. Here's how it works.

Discovering your workspaces and collections

To start out, you do an authenticated GET on a server's Atom URL to get a description of the services available to you. You get back an an Atom Services XML document that lists the workspaces and within each the collections available. A workspace could be a blog, a wiki namespace or content collection that you have access to via your username/password.

Each workspace can contain two types of collections: entries and resources. Eventually, the spec will probably allow for (at least) five types of collections: entries, categories, templates, users, and generic resources.

Here is an example of a services document XML for a blog user with access to two blogs "My Blog" and "Marketing Team Blog":

<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://purl.org/atom/app#">
     <workspace title="My Blog" > 
        <collection contents="entries" title="Blog Entries" 
            href="http://localhost:8080/roller/atom/myblog/entries" />
        <collection contents="generic" title="File Uploads" 
            href="http://localhost:8080/roller/atom/myblog/resources" />
     </workspace>
     <workspace title="Marketing Team Blog">
         <collection contents="entries" title="Blog Entries" 
             href="http://localhost:8080/roller/atom/marketingblog/entries" />
         <collection contents="generic" title="File Uploads" 
             href="http://localhost:8080/roller/atom/marketingblog/entries" />
     </workspace>
</service>

Working with collections

So, a workspace is a blog and a blog contains collections of things like entries, uploaded file resources, categories, etc. All of these collections are handled the same way and respond the same way to the HTTP verbs. All support paging, so the server can return a collection in easy to digest chunks. All support query by date, so you can filter collections by start and end date.

To get a collection, do a GET on it's URI (that's the collection's 'href' as listed in the services document).

The services document specifies a URI for each collection. If you do a GET on a collection URI, you'll get back an Atom Collection XML document that lists the first X number of members in the collection. If there are more than X members, then the document will include a next URI which you can use to get the next batch of members. You can also specify an HTTP Range header to restrict a collection to only those between specific start and end dates.

Here is an example of a the collection document XML you might receive by doing a GET on the Blog Entries collection from My Blog above.

<?xml version="1.0" encoding='utf-8'?>
<collection xmlns="http://purl.org/atom/app#"
   next="http://localhost:8080/roller/atom/myblog/entry/77088a1" >
   <member title="The Connells: Fun and Games"
         href="http://localhost:8080/roller/atom/myblog/entry/7700a0" 
         updated="2005-04-16T23:07:08-0400" />
   <member title="The Connells: Boylan Heights"
         href="http://localhost:8080/roller/atom/myblog/entry/7700c9" 
         updated="2005-04-15T23:06:09-0400" />
   <member title="The Connells: Gladiator"
         href="http://localhost:8080/roller/atom/myblog/entry/7700c8" 
         updated="2005-04-14T14:05:31-0400" />
</collection>

Each member in a collection document has a title and a URI. To get a member of a collection, you do a GET on the member's URI. To delete it you use DELETE. To update it you use PUT. Here's an example of the entry XML you might receive by doing a GET on the first member of the Blog Entries collection example above:

<entry xmlns="http://purl.org/atom/ns#">
  <title>The Connells: Fun and Games</title>
  <id>7700a0</id>
  <updated>2005-06-01T19:07:45Z</updated>
  <content type="html">
     Let me tear down into your heart
     Let me take a seat and stay awhile
     Let me have a half of your whole  
     Let me keep it for myself awhile  
  </content>
</entry>

To add a member to a collection, you simply POST the member to the collection's URI. If you're POSTing a new entry, send the XML for the entry (example entry XML shown below). If you're POSTing a file upload, then send the file.

That's it. Pretty simple huh?

What about authentication?

The Atom spec requires that a server support either HTTP digest authentication, which can be difficult for some bloggers to implement (depending on their ISP and web server), or CGI authentication, which can be a lot easier to implement (I believe WSSE qualifies as CGI authentication, and that's what my Atom implementation uses).

What about devices with limited HTTP support?

Some devices have crippled HTTP client capabilities. For example, some Java J2ME powered cell phones can't do an HTTP PUT or DELETE. If you can't do a PUT or a DELETE, you can use POST instead with a SOAP wrapper that specifies a Web-Method of PUT or DELETE. Atom servers are required to support SOAP POSTS and returning results in SOAP envelopes.

What about draft vs. published states for entries?

Still undecided. Some folks suggest using different collections for entries in different states (draft, approved, published, etc.). But it's more likely that a new element will be introduced in the Atom format to specify the state of an entry.

Summary

That's my summary of Atom protocol as it stands today. I think it's a great improvement over existing blog APIs in terms of features and design. And it's not very difficult to implement. I know because I'm almost done with my server and client implementations. I hope to release them shortly for review. The release will probably be a standalone release of Roller (the Atom server) and my BlogClient UI (the Atom client).

If you see some opportunities for improvement in the protocol, please join the Atom Protocol mailing list and help out. Last call for spec changes in now slated for October. And for the Atom experts out there: what did I get wrong? Leave a comment.