Subject: [CODE4LIB] Q: AtomPub (APP) server libraries for Python?

From: Godmar Back <[email-masked]>
Date: Wed, 28 Jan 2009 08:13:58 -0500

Hi,

does anybody know or can recommend any server side libraries for
Python that produce AtomPub (APP)?

Here are the options I found, none of which appear suitable for what
I'd like to do:

amplee: http://mail.python.org/pipermail/python-announce-list/2008-February/006436.html
django-atompub:  http://code.google.com/p/django-atompub/
flatatompub http://blog.ianbicking.org/2007/09/12/flatatompub/

Either they are immature, or require frameworks, or form frameworks,
and most cannot well handle foreign XML.

 - Godmar

---

From: Ed Summers <[email-masked]>
Date: Wed, 28 Jan 2009 09:41:03 -0500

Hi Godmar:

Perhaps this will seem backwards, but rather than trying to adapt (or
create) a generic AtomPub implementation I've been using vanilla
django, and just rolling my own atom feed and service documents as
standard templates. The advantage here is that my code is custom
suited to my task at hand: namely a SWORD implementation to allow
known parties to upload BagIt content packages to a "repository".

Django's support for RESTful practices [1,2] make it relatively easy
to do the RESTy things that atompub requires. I imagine the same can
be said of other web frameworks RubyOnRails, PHP, Catalyst, etc. I
wonder what Ross' mileage has been with his Jangle [3]
implementations?

The one caveat to this was handling large POSTs of data, if your
atompub service needs to handle these. Django has good support for
streaming form file uploads (multipart/form-data). But other POSTed
media is made available via HttpRequest.raw_post_data, which slurps
the whole message body into memory--which is problematic for large
POSTs.

The nice thing about AtomPub (RFC5023) [4] is that it's a super-clean
spec, written by some of the luminaries of the web world. So if you
are interested in how the web works as an architecture it's a lot of
fun. It's also a nice gateway into the IETF family of standards.

The one thing I didn't roll myself was code for handling
authentication with HTTP BasicAuth. At the time (perhaps still) HTTP
BasicAuth wasn't part of core django. But I found a nice snippet that
provided a view-by-view decorator for controlling this [5].

//Ed

[1] http://www.pointy-stick.com/blog/2008/12/09/implementing-http-services-django/
[2] http://www.pointy-stick.com/blog/2008/12/13/etags-and-modification-times-django/
[3] http://www.jangle.org/
[4] http://bitworking.org/projects/atom/rfc5023.html
[5] http://www.djangosnippets.org/snippets/243/

---

From: Ross Singer <[email-masked]>
Date: Wed, 28 Jan 2009 09:43:35 -0500

Godmar,

What do you need the library to do?  It seems like you'd be able to
make an AtomPub server pretty easily with web.py (you could use the
Jangle Core as a template, it's in Ruby, but the framework it uses,
Sinatra, is very similar to web.py).

It seems like there are two things you need here:

1) something that can RESTfully broker a bunch of incoming HTTP
requests and return Atom Feeds and Service documents
2) an XML library that doesn't choke on foreign characters. (I assume
you're using ElementTree now?)

Is that right?
-Ross.

---

From: Godmar Back <[email-masked]>
Date: Wed, 28 Jan 2009 09:55:57 -0500

> you're using ElementTree now?)

I meant foreign markup, as in foreign to the atom: name space.

Let me give an example. Suppose I want to serve results the way Google
does in YouTube; suppose I want to return XML similar to this one:

http://gdata.youtube.com/feeds/api/videos?vq=triumph+street+triple&racy=include&orderby=viewCount

It contains lots of foreign XML (opensearch, etc.) and it contains
lots of boilerplate (title, link, id, updated, category, etc. etc.)
that must be gotten right to be Atom-compliant. I don't want to
implement any of this.

I'd like to write the minimum amount of code that can turn information
I have in flat files into Atom documents, without having to worry
about the well-formedness or even construction of an Atom feed, or its
internal consistency.
(Perhaps similar to Pilgrim's feedparser, except that this library a)
doesn't handle all of Atom, b) doesn't support foreign XML - in fact,
doesn't even use an XML library), and is generally not intended for
the creation of feeds.

Given the adoption RFC 5023 has seen by major companies, I'm really
surprised at the lack of any supporting server libraries; perhaps not
surprisingly, the same is not true for client libraries.

 - Godmar

---

From: Ed Summers <[email-masked]>
Date: Thu, 29 Jan 2009 03:40:42 -0500

One other suggestion here. If the issue is that amplee, django-atompub
or flatatompub lack the ability to layer in non-atom markup you might
want to look at adding this functionality to your favorite among them,
and seeing if the changes could be rolled back into the project.

I realize this is kind of an obvious thing to say. I know I sometimes
overlook it as an option. It is a real challenge sometimes to dig into
someone else's codebase...but it's a rewarding and connecting exercise
I think.

//Ed