The sad state of weblog APIs

2005

created on Sat, 2005-12-10 22:31

Actually, the first issue I have is that it's called a weblog API....it's a CMS API, or maybe just a publish-editing API. We're stuck in this concept of "blog". With structured blogging (yep, that damn word again...but I guess that's what you get when all you have is one big text blob to shove data structures into*) just on the horizon, tools like ecto, Qumana, and MarsEdit are going to be pushed to work with the myriad number of web apps out there, and the different ways they've implemented some of the loose aspects of these APIs. Actually, this post was inspired by Gus Mueller's post on the MarsEdit 1.1 beta, where he mentions "the sorry state of weblog api implementations right now, and yes- that even includes you atom."

So...what to do? Well, this is one of the things that needs work both on the web app side and the client side. On the web application side, I'm hoping we'll have a special interest group focused on this at the Open Source CMS and Blogging Tools Summit here in Vancouver right before Northern Voice and MooseCamp.

*Why the rant about blogging and "big text blobs"? Well, I'm biased by my tool of choice, Drupal. We've got separate content types for structured information, like events or reviews, and so don't need to take a step back and find ways to mark up structured information inside text. Of course, we'll support structured blogging standards and formats as they arise (and yes, those funky XHTML level microformats, too). Canter's Law, and all that.

My final comment: in all of these things we develop, we have to think less about talking to single point aggregators and namespaces (e.g. Technorati for tags), and think more about every single website as producer and consumer. Aggregation everywhere, and a rich mesh directly between my site and your site, between me and you, not intermediated by several large players.

Heck, if those large players want to come along and crawl my standard RSS 2.0 categories, they can win by giving us kick ass interfaces and great tools for slicing and dicing. But I'm not going to work with your made up formats, I'm going to work towards global standards that work for everyone.

Tags:

Add new comment

Working Effectively With drupal

On December 11th, 2005 Jon Husband (not verified) says:

Hey, boris ... Jon Husband here. I can't tell you the number of times, or the detailed, step-by-step documentation made available, that would help Qumana play more nicely with Drupal, based on the time I have spent with Ean Jackson and his Bryght site ClubFatAss.com. He says, and I don't think I'm talking out of school here, that it's hard to get anyone's attention at Bryght with respect to that, and I have also tried to meet with kk in order to find out what it takes to see what can be done to help Q and Drupal play more easily together. I'd be glad to sit down and talk with you about that .. there's lots of *diagnosis* available from trying to get it to work better with CFA.

Standards

On December 11th, 2005 Boris Mann says:

I've always strived for and advocated standards. As far as I know, Drupal adheres to the Blogger API, the MetaWeblog API, and the MovableType API -- except that all three of those aren't really standards, with differing interpretations.

If your tool talks to those APIs, then everything should work out of the box. But my point with the post is that we need to not only make sure that standards are being kept, but also that these standards are simply not sufficient: we're "beyond blogging" and need ways to for the current methods to be extended.

If there are any specific bugs that you've noted, you can file an issue against the Drupal blog API project here. That's the great thing about open source -- we work together to fix these things.

Thanks ...

On December 11th, 2005 Jon Husband (not verified) says:

... for the reply, Boris. That's what I understood, too .. and what I initially told Ean. Q works well with all those API's. Therefore, it must be something with respect to the customization of the CFA blog/site that bothers his use of Q.

I understand, appreciate and agree with your points about current standards not being sufficient ... and yes, publishing what people are producing is moving "beyond blogging" in some circles.

User Error or Finger-Pointing?

On December 12th, 2005 Ean Jackson (not verified) says:

Hey Jon,

Thanks for making reference to me as a typical end user. I believe the thread would benefit from more input from this perspective.

As an end user, I look to technology not as an end in itself, but as a means to an end. My aim is to leverage technology to achieve my goals, if and where it makes sense to do so. Where it concerns tools, I measure success based on the tool's ability to complete the job to a high level of quality as quickly and painlessly as possible.

As I pointed out to you, I made a commitment to Drupal a year ago. Based on the information I have at this time, Bryght is the best choice for www.ClubFatAss.com, www.ebus500.com, www.whatsweb20.com and www.areopod.ca. Since electing to go with Bryght, I've come around to your opinion that blogs are good and that I should blog.

The question we addressed is whether Qumana offers a better way for me to blog to the sites I blog most on right now: Bryght sites. Based on the examples you showed me, Qumana promises to be a better way to create blog posts than the Bryght editor I've been using.

In practice, Qumana does not work at all well with the Bryght sites I use. You know this to be true because we have spent a lot of your time, your tech support team's time and my time to try and make it work. I believe your team has the specific feedback on what worked and what didn't based on our interactions.

I'd love to offer you a glowing testimonial, but I can't.

You suggest that Qumana works like a hot damn everywhere but on the CFA Bryght site. As an end user, that doesn't matter a rat's tail to me because it doesn't work for me.

Is it a Drupal problem? Is it a Bryght problem? Is it a CSS problem? Is it a Qumana/Bryght problem? Is it an API problem? Is it user error? I don't know....that's a problem that the vendor, not the end user needs to resolve.

I'd love to give the tool another try. Let me know when it works! =;-)

Jackson

Qumana Does Work

On December 13th, 2005 Shane (not verified) says:

I have a whole lot to say on this subject, but here is just a quick note in regards to Ean's evaluation of Qumana. Qumana does work - and I use it on a daily basis.

Qumana isn't perfect, but for what it does do - it does it pretty well. There is always room for improvement and I send in suggestions/feature requests all the time.

But, your suggestions about whether or not it is a Bryght/Qumana problem, user error problem are definately on the right track.

What I believe the issue to be is blog APIs are all the rage. Yet, what is lacking in Drupal (not to mention every other CMS out there) is a story API and a page API. It would be great to be able to interface with those types of data in Drupal.

Essentially, what I am trying to say is that, Qumana works and will continually get better - but Drupal needs to create some APIs to make the majority of its node types accessible to software like Qumana.

So, your evaluation and questions as to where the problem is with Bryght/Qumana is somewhat correct - the problem is really "all of the above" and "a little here, a little there".

Bryght HowTo updated with Qumana HowTo

On December 13th, 2005 Roland Tanglao says:

Check out the just added How To Use Qumana with Bryght and Drupal sites

Interesting perspective

On December 15th, 2005 Robert Douglass (not verified) says:

The way it has worked so far is that some leading expert with lots of market clout has made APIs for the things they want to get done, and the Drupal community has reacted and implemented those APIs. This indicates a sort of visionary-enabler relationship. What you're suggesting is that some of the things Drupal does are visionary, and that they need the same enabling for the rest of the world as those other APIs. In other words, we should be taking the "Build it and they'll come" mentality; expose more Drupal functionality via an API and someone is bound to build the tools to use it? Very interesting points.

More Functionality, Yes. Maybe Waste Some Time, Probably.

On December 15th, 2005 Shane (not verified) says:

"Make it available" and the best technologies, ideas and tools will follow. The only danger is creating an API which looks great on paper, might not work entirely well in the real world - or at least, in the hands of a non-technical person.

One of the BIG, HUGE issues I have with most "Web 2.0" technologies and the opening of of some awesome APIs is they are still in the hands of the tech-heads who create them. The technology application makes sense to me and nerds alike - but don't make a whole lot of sense to those who might want to use them. Providing a tool like Qumana is awesome but they don't neccessarily want to know how it works. So, telling them to "select the appropriate API" might cause a few brains to implode. The best case scenario is they might understand 1% of what a blog tool is - but are probably baffled by the term "blog" in the first place.

And, sorry to say, documentation doesn't mean jack-jellybeans to people who just want to "write some stuff on the net" when it is written in such a way that they must understand the concepts behind it.

So, yes, making some Drupal-based APIs is rocking the boat in a forward direction - and like Roland has said in the past: "Wouldn't it be cool that a year from now, you can provide a client with a tool where all they need to do is click on the node they want to edit, hit save, and the site is automagically updated?"

I just didn't think it would take so long to start down that road. Blog-centric thinking creates unhappy Shane. :)

ean: perhaps you might want to give the latest version a try

On December 13th, 2005 Roland Tanglao says:

I just installed the latest version of Qumana and tested it on a 4.5 site (which is what CFA is) and it works perfectly (as Shane attests to in his comment below). Check it out at:
http://support-test45.bryght.net/node/23

Re-use existing APIs

On December 15th, 2005 Robert Douglass (not verified) says:

Fortunately, when it comes to cross-site aggregation, we have perfectly useful API out there already. Two that come to mind are the Upcoming.org API for events and venues, and the Flickr API for images. I would much rather invest my time and effort into building software (like the Upcoming.org module for Drupal) that allows two sites to share event information directly with each other (no need for Upcoming... just use the API as a two-way street), than writing software that embeds and scrapes event information in the text-blob of my blog.

Imagine how fantastic it would be if you could use your Flickr publishing tools (Flock!) to publish photos to any web site? These are the APIs that we need in the blogging world.

Again....beyond blogging

On December 15th, 2005 Boris Mann says:

There are no APIs for inputting event data remotely, or for what is now a desktop blogging tool to even display such fields. But your comment on embedding event info into the "text-blob" of your blog is right on target...but other tools don't have that luxury. I think Drupal can play a role by 1) recognizing and aggregating such event content and b) we may as well output the metadata in our event nodes, since it would be little effort and would make us interoperable with other systems.

And on your other comment...yes, there are many things that Drupal does that other systems don't. Even framing it as a "blogging" system is the wrong way to go about it. In the blogging world, we have all the APIs that are needed for the simplistic functionality of those tools. Drupal can pretend that every node type is a different blog, or mimic the MovableType filter system, but potentially needs to move much beyond that.

One example is free tags. If implemented at all, blogging tools will kludge in Technorati tags into the body of the post, rather than be able to use Drupal's native support for tagging.

I need to do some more thinking and examining of the Atom Publishing Protocol, and how it can be extendedm as the MetaWeblog API a) doesn't look to be extensible and b) has the word blog in the title. Then, of course, we need desktop tools to implement it...

But there is!

On December 15th, 2005 Robert Douglass (not verified) says:

Boris, using a RESTful API, one can add events remotely to Upcoming.org or any Drupal site with the Upcoming module installed. Check out their API:

http://upcoming.org/services/api/

There is no desktop tool, but it isn't a big stretch of the imagination that one could build an extension to Thunderbird, or use exported data from Outlook to do this. iCal import would go a long way towards making remote event authoring a reality.

The Upcoming module is to Drupal for events what the blogapi module is for text publishing. The future, unwritten, Drupal-Flickr API module would do the same for photos.

I know, I get this

On December 15th, 2005 Boris Mann says:

Desktop tools, man, it's all about desktop tools. Regular people want the stuff on their desktop to talk to their web apps. Everything is *possible*....but if it's not built around standards, it's chaos. There is no standard, at least not until CalDAV matures.

And for pictures, there is already a Drupal module that clones the Gallery API, so that Drupal's built in image module works with the Gallery iPhoto plugin, for example.

But that's also not a widespread standard: ideally, the Atom publishing protocol could be extended to handle different types of content, and it could all be done with ONE standard. Cloning APIs is neat and has some great benefits, but ultimately does not move the ball forward when it comes to standards.