Now blogging at diego's weblog. See you over there!

why (not)echo is important


Daniel was commenting on yesterday's surprise announcement by Blogger that they are dropping their 2.0 API in favor of NotEcho, and among other things he said:

No one has pointed to any benefit of all this work, something that can't currently be done, that will make for a compelling new feature for my/our users. Anyone? I'm not asking you to reveal your new killer feature, but to remain at essentially the same place I'm at now, I'm being asked to rewrite to support "notEcho". Where's the upside for me? I'd like to understand. No politics. Just tech. Thanks!

There have been other arguments about this elsewhere, but I thought it would be useful to give my point of view. So here go my reasons for supporting NotEcho, and endorsing it for use within the software on which I work.

No politics. Just tech.

My view is simply that of a developer, and my reasons for thinking that NotEcho is good are simple (but I'll try to be thorough in laying them out, so the explanation might not be as simple as the reasons :)); here are the most important.

clevercactus, allows both reading of RSS feeds and posting to weblogs, so I've experienced both sides (ie, "reading" and "writing") of this situation in the last few months.

Right now, to support reading/writing, a tool has to read three different weblog syndication formats, and even within the same format some components vary in how they are represented (e.g., Dates). Furthermore, since specs are ambiguous about certain things mean (e.g., link v. guid) the parsing has to be a bit too lopsided.

The blog API situation is even worse. Theoretically Blogger, MT, and Radio support the blogger API, and both MT and Radio support metaweblog. You'd think that at most I'd have to support BloggerAPI and metaweblog. But that's not the case. Again, differences in spec, ambiguities, etc., mean that the MT implementation differs from the Radio implementation. Actual code examples of the differences can be seen in the blogging APIs mini how-to I wrote up back in May, where (at Sam's suggestion actually, in the comments to my original review of blogging APIs :)). The reasons for the discrepancies may be technical, or they may very well be political, I don't know. I don't care either. At this point, this is the situation, and it's what we have to live with.

So, three tools, three implementations.

LiveJournal has its own API. Another implementation.

And so on.

Not good.

Now, according to the RoadMap, NotEcho will be supported by all weblogging tools. Blogger dropping 2.0 is excellent news: it shows their commitment to the new spec, which includes assigning people to work on it. SixApart is also involved, and it will include NotEcho support in their upcoming TypePad service as well as on MovableType. Dave has (tentatively) stated that he will recommend UserLand to support the format. LiveJournal, which currently has its own (more powerful) API will also support it. And although the process through which NotEcho is being developed at times seems to be a bit chaotic, it is clearly open to anyone (this is not a comment on whether other processes were/are open or not, simply it's an important quality of NotEcho), all of the information is in one place, with additional discussion happening on Sam's weblog. This helps immensely in involving other tool-developers and providing a channel through which they can participate, further increasing the likelihood that support will grow in the future. And the high level of (promised) support for echo today, the good foundation in which it stands for the future, and the clear "balkanization" of the current implementations, leads me to my first reason.

As an example: Clevercactus already has RSS 2.0 and metaweblog support, which allows it to interoperate with several, but not all, tools (example: LiveJournal). But by adding NotEcho support (when it's done) clevercactus will be able to interoperate with all tools using a single API, both for reading and writing. That means, across the board, a single system that works with all the others. This is an eminently good reason as far as I'm concerned.

Tech reason #1: Use of a single format across multiple tools means less code to develop, debug, and support, both for content syndication and creation. This benefits users directly in that we can spend less time spent implementing the same newPost() method in different ways and more time to provide good products for them, or work on new features.

I mentioned earlier the problems with spec-ambiguities. These are found both on the RSS spec and on the BloggerAPI/MetaWeblog specs. Before anyone goes ballistic, I'll acknowledge that there is debate on this point as well (as we can see in all the acrimony in the comments for Mark's post 'leave RSS alone' today.) But the debate only illustrates my point: whether it's actually properly spec'ed or not, or whether it's because of political problems, or a bit of both, the end result, the plain fact, is that there are different views on how things should work. This means support problems.

This point, summarized, is: even if everyone was using only a single set of specs, say, metaweblog/RSS 2.0 or even Blogger API 1.0/RDF 1.0, there would still be incompatibilities due to actual or perceived ambiguities in the specifications.

So:

Tech reason #2: A full, unambiguous specification of all components of weblogs (syndication formats, APIs, etc) will also improve interoperability; it's not enough with everyone using the same spec. Just like today you can look at a call to a POP server and decide if it's standards-compliant or not, we should be able to look at a feed, or ar the functions provided by a tool and decide if it's compliant or not. This will also save time for developers and improve the user experience.

A final tech reason for me is to properly codify (as per Tech Reasons #1 and #2) emerging practices that are simply not possible today. A specific example has to do with comments and trackbacks.

Both comments and trackbacks are growing in use as a way of enriching interaction in sites. Neither comments nor trackbacks are properly defined in RSS 2.0 (for reading) or in the metaWeblog API/Blogger API (for writing). This means that I simply have no standard way of providing client-side functionality for comments, since I can't support each person's implementation of a comments feed. Since the RSS 2.0 spec is frozen (as are the other specs) there is no way this can be supported with the current spec.

Tech reason #3: An update of the specs to include concepts currently in wide use (that is, a codification of current practice, allowing room for extensions based on it) is both important in its own right and eminently useful technically, to provide new functionality and improve creator/consumer tools to the next level.

As a postscript: reasons #1 and #2 seem to depend on everyone adopting the format, but that's not the case. Even if half of the tools mentioned in the roadmap adopt NotEcho initially, it would still be a win, since a larger number of products would be able to interoperate.

Note: This has proven to be a bit of an emotional subject lately (for a section of the blogsphere at least...), so I'd appreciate it if the comments, if any :), remain on-topic, that is, they talk about the text itself, or the ideas, rather than about the people that stand for/against an idea, both for comments on comments, or comments on the entry. Thanks.

Categories: technology
Posted by diego on July 2 2003 at 8:44 PM

Copyright © Diego Doval 2002-2011.
Powered by
Movable Type 4.37