May 03, 2003
a review of blogging APIs
As I was looking again at the space of remote-access APIs for weblog software (working on the XML-RPC Weblog Sync feature of clevercactus), I found that there was no side-by-side comparison of the main available APIs, or list of links of material to read. So here goes, in the hope that it will save time for others in the future. :)
Update: May 6 -- here is an introductory mini-howto I posted tonight on blogging APIs.
Another update: May 17 -- a follow up with a reply to some of Evan's comments, and some more discussion of the Blogger API 2.0.
As always, comments & corrections are most welcome!
Why an API?
First of all, why is an API necessary? The answer to this question is useful to me in evaluating how the APIs stack up against each other. In my view, the API should ideally provide programmatic access to all the functionality in the product. Weblog software is typically server side (even Radio, which is client-side, is actually running a web server in the client), and so the APIs are crucial to provide client-side access when needed. We don't live in an ideal world however, so at a minimum the API should provide:
- The ability to create new posts (specifying not just content but dates, categories, etc.)
- The ability to edit posts (again, including modifying not just content, but also dates, categories, etc.)
- The ability to discover information about a user's accessible weblogs, information on how many posts there are, and so on.
- The ability to retrieve any post, or a set of posts.
These are the main tests that an API has to pass to be truly useful as far as I'm concerned. Reading recent posts is not as important, IMO, since you can obtain those by reading the RSS feed of the blog anyway.
As a side note: these are my ideal features for a weblogging API for the usage I have in mind, which is letting cactus deal with weblogs as another data/source sink, which would in the end let weblogs replace emails in many situations, particularly for mailing lists. You would be able to create a full "backup" of your weblog in your local machine. You would be able to sync the contents of a space to a weblog, post new items, and read the feeds, creating a "roundtrip experience" on the client, while retaining the flexibility to use the weblog (both for reading and writing) for the situations when that's necessary. That is, let the user choose the appropriate tool for the appropriate time. Other applications will certainly have different needs, but I think that what I'm looking for is more or less the high end of what you'd want to do (at the moment--who knows where we'll be in six months!).
On to the APIs that are available.
What's out there: an overview
First, there seems to be a growing proliferation of blogging APIs. There are tons of open-source blogging software coming out, and some of them are also implementing their own remote access APIs. This only creates confusion and problems for developers.
One bright spot is that, so far, all APIs so far are being written on top of XML-RPC although I've seen whiffs of SOAP implementations. The fact that XML-RPC appears to be the de facto "standard" feels strange: usually it's high-level APIs which should be the standard, using any number of transports (e.g., XML-RPC, SOAP, BEEP, whatever). However, this is the situation at the moment, and it doesn't appear that there is a huge drive to change it for the foreseeable future. At a minimum, the fact that they are all being written in XML-RPC means that there's less transport headaches.
As far as what I reviewed, there seemed to be three main API contenders: the Blogger API v1.0, the MetaWeblog API, and the LiveJournal API (Those are the original source links; Userland maintains a main list of APIs here). Those three main API mirror three of the main blogging tools available: Blogger (now owned by Google as we all know), Radio and LiveJournal. MovableType, also very popular, only adds extensions on top of the Blogger and MetaWeblog APIs, as I mention below. The main developers of these APIs have been Evan (Blogger) and Dave (MetaWeblog). LiveJournal doesn't seem to identify with any particular authors per se. Ben & Mena, as developers of MovableType, also hold some sway in the community (I would think).
A developer preview of the Blogger API 2.0 was released last December, but the location given for the document now responds 'file not found' (which might be related to the Google purchase of Pyra and their subsequent adjustment of plans--I don't know). Strangely, the release was not mentioned in Evan's site, but it was mentioned in Dave's and Ben & Mena's, as well as in a zillion other blogs. Evan did respond to comments from Dave, who was asking for a move towards uniformity so that only one API has to be supported.
Of those three, the APIs to focus on are, IMO, Blogger 1.0 and MetaWeblog. All major blogging software implements both (with the notable exception of Blogger), and other, less known but still popular packages such as blojsom do as well. LiveJournal supports their own API and nothing else, and no one else seems to support the LiveJournal API. As far as I'm concerned, that makes it a closed system and so third in interest by a mile. Why would you write software that works with a single vendor? Microsoft might be able to pull that off, but that has to do more with monopolies and bulging bank accounts than with developers liking the idea. That said, the LiveJournal API is actually quite complete. If it was more widely supported, or if you really, really needed interaction with LiveJournal, it would be worth taking a second look. The Blogger 2.0 API is also out of the race for the simple reason that access to it is for developers only; it's still in flux, not deployed, and not widely supported. It seems that the API is moving closer to the functionality of the metaWeblog API, but as Ben commented there is still room for improvement and a lot of confusion built in. In particular, the new Blogger API, while being incompatible with 1.0, retains the method call names, something that's not, shall we say, ideal. Finally, MovableType has its own extensions to the APIs, but since it implements both Blogger and MetaWeblog I won't go into those. ManilaRPC is probably the oldest blogging API there is, but again since it applies only to Manila, and no one else supports it, I won't go into it in detail.
The comparison: Blogger API vs. MetaWeblog API
Before we get into the specifics, I can give one general impression: The Blogger API is a joke, and a bad one at that. This is probably to be expected since it's about two years old, but it's really disappointing to see that one of the most used weblog tools has such crappy developer support. The MetaWeblog API is much better, although it has one or two shortcomings as well (measured by the "tests" I mentioned above). The Blogger API has an incredibly simple-minded view of what a weblog post is, and it is completely, and I mean completely innapropriate for what people do with weblogs today, from posting images to using audio and so on.
To see why, look at the following lists of methods in each API:
Blogger API 1.0
blogger.newPost: Creates a new post.
blogger.editPost: Edits a given post.
blogger.getUsersBlogs: Returns information on all the blogs a given user is a member of.
blogger.getUserInfo: Authenticates a user and returns basic user information.
blogger.getTemplate: Obtains the main (or archive) index template of a given blog.
blogger.setTemplate: Sets the main (or archive) index template of a given blog.
MetaWeblog API
metaWeblog.newPost: Creates a new post.
metaWeblog.editPost: Edits a given post.
metaWeblog.getPost: Obtains a given post.
metaWeblog.newMediaObject: Uploads an image, movie, song, or other media object from a user's computer to the user's blog.
On the surface, the Blogger API appears to be more complete than MetaWeblog. This is not the case however, and there's a simple reason: the Blogger API considers
the content of a post to be simply a string with no parameters whatsoever allowable. For example, when you
editPost using the Blogger API, you can't change the date of the post, or do anything except modify its main text content. Yuck. Again, this comes from a simpleminded view of what a weblog post is, and one that is entirely innapropriate for the use most bloggers give to their blogging tools today.
The MetaWeblog API is, as I said, much, much better. It considers post content to be structures rather than simple strings, and the structures are elements of the item tag in RSS, so you can create essentially anything that you can read. Furthermore, it almost passes all of the "tests" I mentioned above. It doesn't have a way to query for a user's blogs or obtain information, and it doesn't let you edit templates etc. That said, all tools that I've seen implement the MetaWeblog API also implement the Blogger API, so you can use the getUserInfo call from Blogger and then use MetaWeblog for postings.
In summary: MetaWeblog API, good. Blogger API 1.0, bad. The Blogger API 2.0 apparently fixes many of these problems, let's hope it gets (re-)released soon.
In the end however, it's unlikely that any developer, particularly small developers, can choose one over the other. We will have to work with both for the foreseeable future, supporting other APIs like LiveJournal separately when necessary.
Final thoughts
A few things that will be important in the future, and are still missing: the ability to edit categories, and to specify things like RSS feed targets, among others. This of course falls into remote configuration of weblog software, rather than use of the software itself. This area hasn't been explored at all, but I think that as more people use blogging software the need to have simple, client-side configuration tools will grow.
Posted by diego at May 3, 2003 02:29 PM | TrackBack
Dave Winer clued me into this one time because it's not very clear, but the MetaWeblog API is a superset of the BloggerAPI - it doesn't live on it's own, but rather sits on top of the BloggerAPI. Thus any app that supports the latter, supports the former (but not vice versa, if you're following me).
You should check out MTs extensions to this as well, here: There's even more stuff in there to support if you're really into it. ;-)
http://www.movabletype.org/docs/mtmanual_programmatic.html
-Russ
Hey Russ,
Interesting. I didn't know it was suppossed to be a 'superset', since most of the methods are duplicates with different names... unless you consider it a superset 'in spirit'. The MetaWeblog spec doesn't mention anything about being a superset...
Re: movabletype, I did mention that, and linked to that page! :) Although for the reasons I explain in the post I didn't really consider it 'a contender' since it doesn't stand up on its own, and it works only for MT. The extensions are very cool though.
Thanks for the comparison and information, Diego. I was checking out the new version of blogger.com yesterday, and there's no mention of anything new on the API front. In fact, it mentions that the existing API should still work: http://new.blogger.com/projects/dano/release_notes.pyra .
There is a bloggerDev mailing list at http://groups.yahoo.com/group/bloggerDev/ where they're discussing the v2.0 API spec, as of April 27th. You have to join the group to view the documentation, however even after joining, I can't see the file, so cannot comment further!
Martin, glad it could be of help. The problem with the link you mention is the same I was talking about in the entry as well--I registered and the link isn't there, which is a bit... err.. suspicious. My intuition is that they've pulled it until the Google thing settles down, and they've figured out what they're going to do.
Sorry, Diego... I'm a bit of a skimmer. ;-)
-Russ
BTW, ManilaRPC is also available over SOAP 1.1, not just XML-RPC.
Dave, thanks for the comments. I agree that MetaWeblog should be "rounded out" with the methods from the Blogger API that it is relying on (I'm referring to what Russ said, see first comment above). Right now it's not clear that MetaWeblog is a "superset" of sorts of the B-API (if that's the case--If you could clarify the history of this that would be great!). MetaWeblog would then support basically all functionality requirements.
Sam, the comment API you linked to is really interesting--I had been looking for something like that but couldn't find it (the term "blog" appears only once in the page and weblog doesn't appear at all--that's why, probably).
Btw, as a follow-up I am now writing a sort of "how to" for using the APIs--even though the spec is reasonably clear, not having ready-to-go examples makes it hard to get started. I'll post it later today.
d
Re: follow up. May I suggest a test case? Take a look at what it would take to represent a simple blog entry with two categories with any of the popular APIs.
We're building a new blogging API based on SOAP (but also extensible to XML-RPC and REST) that takes a slightly diff approach. In our model, the data store is much richer (close to the LiveJournal model), but we also support the same functionality ideas as blogger/MetaWeblog/MT. In fact, we even offer an XML-RPC interface for the same data store. check it out at http://erablog.net/webservices/v1.4/erablogauthor.asmx and http://erablog.net/rcp2/erablog.xmlrpc.
Russ got it right. When designing the MetaWeblog API, I just wanted to broaden the pipe in and out of posts, the other parts of the Blogger API were sufficient, imho (at the time). Now with all the rock and roll in BloggerLand, I want to be sure that we have a basic frozen spec for implementors, so it makes sense to round out the MetaWeblog API.
Jason, how about we work together to get a single API that works for all blogging tools? It's not too late. I think we'll all look back on this moment a few years from now and see this is when we had the opportunity to do something great. Longterm people may forget our products, or who we are, but the API will last if there is a single API that allows you enough flexibility to tune it to your tool. In all that I've seen so far, I don't understand why you can't use the MetaWeblog API. Evan says it doesn't fit, but he didn't explain why. Perhaps you'd like to engage the rest of us in a discussion. It's important, imho.
Diego, (and everyone else) given that MT's extensions to metaweblogAPI are "very cool", what's the general feeling about those extensions being part of MetaweblogAPI 2.0? Anyone see a reason why they shouldn't be in there?
Jason, thanks for posting the link. The new API looks very much like a mix of MetaWeblog and some of the original elements of Blogger 1.0, as I mentioned in the post. To me, it looks as if Metaweblog and Blogger 2.0 are almost the same, except for naming conventions, which essentially prevents interoperability (of course, I might be missing something here).
I second Dave's request. In my mind, there's one hugely important reason for a single API: if there isn't one, then someone, at some point, will come up with a an "uber Weblog API" that encapsulates all of the others, but, obviously, it won't be server side. It will be a wrapper on the client, and it won't be available for everyone (that is, it will be limited to certain platforms, or languages). We'll lose XML-RPC as a common base, which would be bad, since most likely it will be a provider of development tools of some sort. Then whoever controls *that* API will drive it. Who knows? It could even be (gasp!) Microsoft!
The pieces are all there IMO (as I said, unless I'm missing something), all that's needed is an agreement on naming conventions and request/response formats. And both weblog tool providers and weblog software providers would benefit from the simplicity that it would bring.
One thing I'm interested in is what the implications are of what you propose for adding the ability to change the date of a posting. It appears that this would break the permalink feature for most of the the blogging sites.
I do think this is something that could be useful and have found myself entering some posts that I after entering manually changed posting times in the DB. The reason for this was the content was tied to summary of events that happened (radio show review/recap) on that date.
I was able to do this since I am programmer at the
blogging site www.23pools.com but I think it could
be useful for others as well but it seems to break the permalink. BTW my site supports the Blogger API and am working towards adding the MetaWeblog API.
Anil, I definitely agree that some of MT's extensions should be incorporated in some form. For example, MT's API is clean in terms of handling categories, which the other APIs don't consider "core" elements, but to me are.
Also, MT's API includes functions for dealing with trackbacks. Managing BOTH comments and trackbacks programatically *in a uniform way* would be excellent IMO, especially for what I have in mind. If a certain app doesn't support trackback (actually, I think only MT and Radio do --I think I read on Dave's blog that he was working on that at some point, Dave correct me if I'm wrong) then the call just returns "not supported" or something. (Sam Ruby linked to a Comment API above that I wasn't aware of).
For my "tests", the ideal API contains elements of all three at this point.
Diego, I did work on Trackback, and completed my work and passed it off to Jake at UserLand to release it for Manila and Radio. That hasn't happened yet, but I hope it happens soon. We tested our Trackback implementation against all flavors of Movable Type, and a couple of non-MT servers that volunteered. It was a lot of work, more than I thought should be necessary (proves the value of freezing a protocol early) and we require the RDF discovery bits be there. Net-net it works, and conforms to the MT spec in all its variations.
I like, and use, some of the MT extensions in my software. I totally dig how scriptable MT is.
However... my main complaint is that it takes more calls to deal with categories than it does with other MetaWeblog API sites.
For instance, with Manila and Radio, categories are present in the structs returned by metaWeblog.getPost and getRecentPosts. So I can get, for instance, the 10 most recent posts, complete with categories. Just one XML-RPC call.
For Movable Type, I can get the 10 most recent posts, but then I have to call mt.getPostCategories for each post. That's 11 XML-RPC calls instead of just one.
And, similarly, I can set the categories for Radio and Manila via metaWeblog.newPost and metaWeblog.editPost. With Movable Type an additional call to mt.setPostCategories is necessary.
This is mainly by way of illustration of a point I want to make -- the fewer XML-RPC calls, the better. Another example might be mt.getTrackpackPings. I'd rather the list of trackback pings be a part of the struct returned by metaWeblog.getPost (and getRecentPosts).
Diego
The Blogger API is extremely limited compared to alternatives, but maybe it's simplicity is one reason why it's so well-supported?
If I need to knock up an app which integrates with the maximum number of blogging tools (or conversely, write an app which allows the maximum number of blogging front-ends to integrate me), the Blogger API is the best choice... isn't this a case of "Don't worry, be crappy"?
http://www.brainyquote.com/quotes/quotes/g/q138091.html
fwiw I'm personally a big metaweblog API fan and implement that alongside blogger API whenever possible.
Timothy, I wouldn't assume that it wasn't answered because there was no answer. If I were coding this from scratch I'd return an array in place of a string if there was more than one category. In the post you point to Charles is already saying he's annoyed and Sam says he prefers SOAP. Somehow I got the idea that neither of them was really looking for the answer, they were looking for a chance to be emotional or partisan. Had Evan, Brent, Mena, Ben or Anil asked me, I would have offered the above. In other words if someone is really doing the work and not tire-kicking, they tend to stick to the basics without adding the extra oomph that Sam often does, as does Charles. That's the trademark of a real developer -- they respect other developers, at some level. The tire-kickers are looking for something else. I don't nibble on every invitation for flaming.
I imagine that's more than you want to know, but the tendency of these communities to flame, particularly at me, makes me reluctant to answer questions sometimes.
IMHO sticking to the basics would mean simply sending RSS 2.0 without any structs, arrays, or other mappings. That's why I recommend the commentAPI.
I've also personally implemented pingback, trackback, the comment API, and any number of other protocols.
I just spent a few minutes checking the spec and how Radio works, and they both use a list to transport categories, so I don't see what the problem is if there's more than one category.
"For categories, pass an array of strings of names of categories that the post belongs to."
http://www.xmlrpc.com/metaWeblogApi
Timothy -- I send multiple categories via the MetaWeblog API all the time in my software. It's an array, as Dave points out. Piece of cake.
Brent: interesting that your solution hasn't come to light sooner. I'm glad that it has and a productive conversation has begun. How are you/would you propose denoting the primary category from the others? Have you submitted this feature request/fix to SixApart?
Timothy, as far as I know MovableType could just add parsing of the parameters. This is from their docs on MT's programmatic API v2.63 (link in the post):
"The struct content can contain the following standard keys: title, for the title of the entry; description, for the body of the entry; and dateCreated, to set the created-on date of the entry."
It adds some MT-only parameters as well. For MetaWeblog you can call "metaWeblog.getCategories". If you're using MT's API, it has a call "mt.getCategoryList" that returns the possible categories, and then you have to call "mt.setPostCategories" which does the trick.
Timothy -- I hadn't realized that it was a solution that needed to come to light. I just thought it was how it worked, that's all.
Primary category: first item in the array.
I haven't submitted this to the Movable Type folks yet because I've been busy. But I've been meaning to.
Timothy -- it was in the MetaWeblog API specification. Certainly it's reasonable to expect people to read the spec before escalating. The spec is pretty simple and short. It's very clear on this.
I guess we assumed you had looked at the spec.
Don't forget that Livejournal is open source and numerous other sites are running their own versions (deadjournal being the largest).
Also, livejournal supports all sorts of things that blogger doesn't (last time I checked) like group-based security.
I'd be interested to see a comparison of the LJ API with the Blogger API that dealt with how much the blogger API would have to be extended in order to work with LJ.
Hi Andrew,
Thanks for the comments. As I noted in the entry, I agree that the LiveJournal API is pretty complete. However, given that it is not compatible with the other APIs, its relevance is diminished. This is just my view, of course, but I think that my situation is not uncommon: uses of these APIs are coming from small developers, and we don't have a thousand programmers to throw at a task. I agree that you can do more things with the LiveJournal API, but it ties you to LiveJournal and so you need to rewrite code for other tools--and so you're left with the choice of having to support one group of users over another. Never an easy choice for a developer, but realistically, if I as a developer have to choose (because of limited resources) supporting either MetaWeblog+Blogger (they work in tandem), and thus providing support for Radio, MT, Blogger, and others that use the API such as blojsom, or LiveJournal, which would only let users work with LiveJournal, it's not really a choice, it's obvious the MetaWeblog+Blogger combination is the way to go.
Regarding the fact that it is open source, while that might be useful for people deploying their own systems, it doesn't affect this discussion IMO, since open source or not, what I as a developer deal with is its API, nothing less, nothing more. The fact that it is open source makes me hope however that the other APIs will be supported in the future though!
My partner in crime in developing blojsom had actually started XML-RPC support for LiveJournal in blojsom. But as you noted above, I think we pretty well covered the bases with our support for the Blogger and MetaWeblog APIs. It's not out of the realm of possibility that we'd have support for the LiveJournal API in the future, but I imagine as the Blogger and MetaWeblog APIs evolve more, we'll update the support for those APIs first. Besides, it'd be an interesting "Exercise left to the developer". Right now we're getting more plugins written as well as exploring other "touch points" for blogging like blojsim (http://blojsim.sf.net), blogging via instant messenger.
I view the metaWeblog API as a set of queries into a database. When viewed that way, all sorts of possibilities can be seen.
Specifically, I would like the abily to edit and add categories, not just list them. I would also like to be able to retrieve a set of blogs based on filters: categories, date range, number of posts, etc.
Why those evil and uncooperative jerks at Blogger, who hate interop and publish incompatible specs that don't work with other people's stuff, don't support the metaWeblogAPI:
blogger.newPost (appkey, blogid, username, password, string, publish)
metaWeblog.newPost (blogid, username, password, struct, publish)
Try not to run clear down to the string versus struct part right away. Take it slow, and compare them carefully.
The reason for LiveJournal having its own API is a matter of tradition. LiveJournal had a client-server protocol before it had web-based posting, and while most other weblog systems were still in diapers. The XML-RPC API is a richer layer atop the original “flat” API.
It's a future plan to retrofit metaWeblog into LiveJournal as a layer over the existing API, although since LiveJournal does some things that most other weblog systems do not, it may be a little tricky… we'll see.
The reason for LiveJournal having its own API is a matter of tradition. LiveJournal had a client-server protocol before it had web-based posting, and while most other weblog systems were still in diapers. The XML-RPC API is a richer layer atop the original “flat” API.
It's a future plan to retrofit metaWeblog into LiveJournal as a layer over the existing API, although since LiveJournal does some things that most other weblog systems do not, it may be a little tricky… we'll see.
Phil, I did as you recommended, and looked really slowly at the two calls, and spotted a difference, right at the beginning. The Blogger call has something called an "appkey" and the MetaWeblog call doesn't. Is that what you're referring to?
That's it exactly. I don't know why they want it, I don't know if it's a good way to do what they want, but I do know that they did it that way, that blogger2 does it that way, and that it's the only significant difference that can't be chalked up to just different styles. Evan said "you will have an appkey", metaWeblog, which was mostly being used where you knew what app was hitting your API because for Radio or MT you own the server and the app, didn't, and blogger2 does. The only use for it that has ever made sense to me would be something like: someone releases an app that does evil things (gets every single post every fifteen minutes, I don't really know what evil you could do), Blogger could block just that appkey while they negotiate with the developer, without having to shut down the whole API. It doesn't seem like very solid security to me, but then Ev's been sitting on Blogger's database watching the crack attempts for years, and I haven't.
Also, I noticed the other day while looking at that one Evhead archive file where the Orlowski piece still exists, that there's another secret surprise archive file - http://www.evhead.com/archives/2003_05_10_archive_default.asp - where he talks about it. A few things I would debate, several more that you will, but more than anything my takeway was what a shame it is that he really doesn't do any writing in public to speak of anymore. I miss the old evhead.
Phil, Dave,
Evan's point on the post Phil linked to is a valid one regarding the appKey; as a centrally managed service they have concerns such as the one Phil pointed too. Blogger has moved (in 2.0) to include a struct for the login; that would solve the compatibility problem, since weblogs that don't need it could just ignore it. Structs seem to be a good option I think since they allow for extensibility without breaking the syntax of the call.
Phil, that's a fascinating memo from Evan. I wrote a memo for Google management last week, after Evan posted that. I hadn't seen his comments until now, and I'm about to go out for the evening so I can't read them carefully. I've pointed to them from Scripting News.
My wish -- a meeting with Evan, the Trotts and myself, keep it simple. We're not really that far apart. We could get unified, I think. I have keynotes at OSCOM and the Jupiter weblogs conferences coming up in the next three weeks, perfect times to make announcements. I know I must be dreaming.
Any new XML-RPC based API should support Unicode content and not 7-bit US-ASCII which is currently implied by the use of XML-RPC string values.
The two obvious solutions with respect to XML-RPC are to encode Unicode strings in some way which is valid according to the XML-RPC spec, for example using the base64 XML-RPC type, or to transition XML-RPC to allow string values with a Unicode encoding.
It would be unfortunate if only the makers of Radio/Manila, Movable Type, and Blogger had a say in how all of this works. This doesn't necessarily allow best of breed to surface, and doesn't give the smaller companies any say. It does promote the concept of the Biggest over the Best.
I think it's past time for weblogging to get a standards group. Unless we want weblogging to turn into another Detroit, with Three Big Weblogging Companies equivalent to the Three Big Car Companies?
(Now, why is it we don't have effective electric or hydrogen powered cars now?)
Certainly it would be bad if only the Radio/Blogger/MT were setting standards in the long run. But it has to start somewhere... that's why I think that even a limited agreement, "less open" between Userland/Blogger/MT would be better than the current situation, where there is no agreement whatsoever. If a "standards group" of sorts could be set up that would be ideal, and much better, but that's probably even more difficult, which is why I tend to favor the other solution, which seems more feasible, *for the moment*. Maybe an initial agreement with the understanding that the stewardship will be phased over to a "standards group" would be a way to get there fast...
I'm all for standards. As for those who get their acts together and nail down the API being the drivers of the standards... well, If you have a "best of breed" laying there, get it out. Otherwise, nail the darned API's down and get on with developing a MacOS blog client that runs on Radio. Enough of the lopsided parity and more platform agnosticism. [no flame bait intended here]
I must say, that I have never been to your website before, but it is very interesting and informative. I found out alot that I never realized that all these blog companies/programs need to do just to make it work. Me, myself, am not a big fan of blogger. But I am a big fan of FREE. I have had many problems with error codes and such...and that was even before google took over blogger. It really sucked to go and update your website just to find out that it isnt working...FOR DAYS. I found the simple solution for that was to make a new template, but that only meant losing that whole page. I looked into Live Journal, but they only allow you to embed into your website if you PAY. Which subsequently, there is a new one...{www.blurty.com} who Live Journal gave them their code to use. But, you have to pay to be able to embed into your website as well. I would love to use Moveable Type, but they use php, and my hosting company doesn't offer it for the package that I have. {they are a free webhosting company...www.breezeland.com} As well as many other places that I have found that have many nice programs. I can send you the whole list to look into, if you are interested. I just don't want to overflow your comments section with links that aren't wanted, unless you say so first. ;)
Good Luck and email me if you want the list.
