Posting to Blogger.com from the command line

Well, you can tell I am procrastinating working today (but you can forgive me after the PIDA GSoc Application was rejected as a mentoring organisation), but I have hacked up an early version of a library (for Python) to manage blogger.com posting.

I was becoming slightly upset with Blogger.com, since it does some insane things like puts BR tags in the middle of PRE elements, which meant the syntax highlighting script I wanted to use was going nuts. I also gradually realised that none of the blogging clients work with the "new Blogger.com" although for me (who has only been blogging a few months) it has been the "only Blogger.com".

So, with a quick search around for documentation from code.google.com, I was able to discover that Blogger.com uses the google GData API with a bit of Atom mixed in. I have no real ideas about these specifications, but http://code.google.com/apis/blogger/gdata.html explains it. Note that another document I found: http://code.blogspot.com/archives/atom-docs.html seems depracated, but I can't confirm that at all.

Python is my language of choice for these things, so I started hacking.

Step 1: Authenticate with Google Login stuff. This is explained in http://code.google.com/apis/accounts/AuthForInstalledApps.html but basically you need to:

  • Send a post request to https://www.google.com/accounts/ClientLogin
  • Set the service value of the data to "blogger" (this had me for a while)
  • Parse the body of the response for an "Auth" token
  • Include the header Authorization: GoogleLogin auth=yourAuthValue in all your requests from thereon in (not obvious from the authentication docs)
Once you have successfully logged in you will want to get some information. Firstly the posting API works on the blog ID, not the blog name. The ID appears in the source of the blog page in this tag <link rel="service.post" type="application/atom+xml" ... but you can also fetch it from the blog's feed from the blog's name (see the API documentation).

Once you have this ID, posting is a matter of using the ID with your auth token, and entering data in an XML format as the post's body. Not forgetting to set the correct content-type for your post to "application/atom+xml". If you have posted correctly, the server returns a 201 Created response.

I have spared you the boring details of making urllib/urllib2 work with these things, but I have written some sample code and a command line client which you can browse online here: http://pygbloggerlib.googlecode.com/svn/trunk/gblogger/client.py as well as accessing the googlecode page (no releases yet) here: http://code.google.com/p/pygbloggerlib/

An example:


>>> from gblogger.client import BlogClient
>>> import getpass
>>> passwd = getpass.getpass()
Password:
>>> c = BlogClient('my-test-atom-blog', 'aafshar@gmail.com', passwd)
>>> c.post('this is a test post', 'this is the body of the test post with some html')
HTTP Error 201: Created
>>>
You can actually see this post online (if I haven't deleted the test blog) here: http://my-test-atom-blog.blogspot.com/2007/03/this-is-test-post.html

Since I never have any spare time, my plans for this library are a bit shaky. It is a toy library in that there are no real tests, and failure conditions are not really dealt with properly. Ideally I will:

  1. Write a PIDA plugin for blogging
  2. Merge it into something like BloGTK, or write a miniature gui client of my own.

I have no idea how to publicize this to the Blogger.com community, but if any of you big Blogger admins or google developers are interested in spreading the word, (or silencing the word!) please let me know.

UPDATE:
(some more useful links)

http://code.google.com/apis/gdata/basics.html
http://www.google.com/base/api/demo/html/demo.html

UPDATE:

Well, editing now works in the library! I know this because I accidentally overwrote this post! Lucky for the unnoficial planet python it was still lying around there!

Popular posts from this blog

PyGTK, Py2exe, and Inno setup for single-file Windows installers

I am lucky, as part of my job, I get to code PyGTK. The downside is of course that I have to deploy these applications on Windows. Now these Windows users (especially at the price they are paying for this stuff) don't install dependencies, don't understand what a scripting language or interpreter is, and frankly they should not have to. Unfortunately, the list of dependencies for a PyGTK application (at the very minimum) is Python, GTK, PyGTK, PyGObject, PyCairo. 5 installers! So very early on in this project I found the way to give them exactly what they want and deserve, a single-file executable installer. There are a few guides online about how to achieve this, but none seem to work, and none are particularly new. How do we achieve this? The toolchain involved consists of two elements: 1. Py2exe website 2. Inno Setup website NOTE: The documentation for all the tools used is extensive, I will not repeat everything in there. Py2exe Py2exe is a distutils extension that searches...
Read more

Kiwi proxy widgets, a common widget API

Image
While we are on the notion of Kiwi , the PyGTK helper library, we should be discussing the proxy widgets. They offer a certain set of advantages over their plain PyGTK counterparts: They have a common signal emission API for change in content They offer a common API for setting and reading their value. They offer validation, and coercion They contain a few general improvements over the plain PyGTK widgets What does this mean? Simply it means you can make any data widget (eg Entry, CheckButton, Combo etc), you can connect its signal "content-changed", you can read the data with widget.read(), and set the value with widget.update(). If you have read any of the previous blogs about adapting Zope.schema fields to widgets, and you are alert, you will notice that this is amazingly useful. It means that we can define an interface for a general InputWidget type, something like: class IInputWidget(Interface): def read(): """Read the value in the widget"""...
Read more

Using threads in PyGTK

Well, all this thought of asynchronicity is getting to me. But since we mentioned how to use subprocesses and Twisted, I think it is only fair to talk a bit about threads. So, what will we be doing? Create an abstraction for running threads in PyGTK Use it Now the thing which we will be wanting to run is a generator, call it "take_really_long". And it will surely block, and might be a bit intensive, and well we obviously need something asynchronous. A generator is a bit nicer to use than a single plain long-running function, because we can update the user interface every time it returns, making it much much easier to do things like Progress Bars. You must remember two things when using threads with PyGTK: 1. GTK Threads must be initialised with gtk.gdk.threads_init: import gtk gtk.gdk.threads_init() 2. Any code that modifies the UI (basically any code) that is called from outside the main thread must be pushed into the main thread and called asynchronously in the main loop, w...
Read more