a ramblings

The Blogger API v. Berylium

Implementing the Blogger API sounds like a useful thing to do. After all, there are a growing number of applications out there that can use it to update a weblog in new and exciting ways. Besides, then we could say that Berylium has the beginnings of an XML-RPC[?] interface, and gearheads like acronyms.

But it's not a perfect fit by any means.

Will It Work Over SSL?
The API requires that a username and password be sent to authenticate the poster. This means two things: 1) I'm giving my password to another application which may or may not handle it in a trusted manner; and 2) unless the entire transmission is encrypted, the password is sent in the clear.

While most people won't care, I'm not writing for most people when it comes to security. What might happen is that in order to use the Berylium Blogger API, you have to enable a sitemember preference and, optionally, create a dummy password for use via the API only. You should also be able to indicate whether you want to allow existing posts to be edited via the Blogger API.


How Will This Work With Folders?
Blogger doesn't have folders, which would seem to be a snag. But wait, any Blogger user may have multiple blogs, and there is a provision for that in the API. So we'll pretend that each folder in a Berylium site that the user can post to is a blog. That should work.


What Fields Are Sent Via the API?
For instance, blogger.newPost takes the following parameters. All are required:
  1. appkey (string): Unique identifier/passcode of the application sending the post. (See access info.)
  2. blogid (string): Unique identifier of the blog the post will be added to.
  3. username (string): Login for a Blogger user who has permission to post to the blog.
  4. password (string): Password for said username.
  5. content (string): Contents of the post.
  6. publish (boolean): If true, the blog will be published immediately after the post is made.
Translated to Berylium:
  1. appkey could be ignored, could be stored for fun as $document->p_appkey
  2. blogid becomes $document->folderid
  3. username is actually an email address that is looked-up to find $document->sitememberid
  4. password is checked against the sitemember record (or member record)
  5. content -- see below for how we might split one field of content (sigh) into title, description, and body.
  6. publish will determine whether $document->status will be new or posted.


So How Will Berylium Parse the Content Field?
The first line becomes $document->title, unless it is too long in which case it is truncated for the title, and then repeated again as part of $document->description.

The next two paragraphes become $document->description, everything else is dumped into $document->body. It might be worthwhile to consider creating a "virtual" BML code that can be used to separate the description from the body in this case.


The Methods and Their Berylium Implementations
  • newPost - will create a new document in the specified folder and return that document's id.
  • editPost - will replace the content of an existing document with new content. This method may not be enabled by default, and/or may only work on recently created documents due to security concerns expressed above.
  • getUsersBlogs - will return a list of all the folders in a site to which a user may post
  • getUserinfo - returns sitemember->name, id, firstname, lastname, and email address (which is redundant, oh well).
  • getTemplate - returns a dummy, vanilla template.
  • setTemplate - gracefully ignored.


How to Implement?
I'm thinking XMLRPC-engine.php to parse the request and then process the appropriate context. Actually, it might not even be that hard to do it with the HTTP engine as long as the URL that's called is something like http://example.com/berylium/index.xml?method=rpc-- the whole thing could be handled by folder-rpc-anonymous-xml. Hmmmm.

By Chris Snyder on March 8, 2003 at 8:57pm

jump to top