RSSCloud Should Not Be Controlled by One Person

I posted a call for comments last night on RSS-Public, the mailing list of the RSS Advisory Board, asking what people think the board should do in response to the ongoing effort to revise the RSSCloud Interface.

The interface has been a part of the RSS specification since the publication of RSS 0.92 in December 2000. It determines how software can use the cloud element in an RSS feed to connect to a server that offers real-time notifications when the feed has been updated. In a nutshell, here's how it works:

A user subscribes to an RSS feed that has a cloud element which identifies its cloud server.
The user's RSS reader contacts the cloud server, asking to be notified when the feed is updated.
When the feed has been updated, the software publishing the feed sends a ping to the cloud server.
The cloud server sends a notification to the IP address of all RSS readers that asked for updates.
The RSS readers immediately request the feed.

Cloud communications can be sent using XML-RPC, SOAP or REST aside from pings, which are sent using XML-RPC.

Dave Winer recently began an effort to revise RSSCloud, persuading WordPress founder Matt Mullenweg to adopt the still-in-progress proposal on all 7.5 million blogs hosted on WordPress.Com. Winer has made three significant changes to the interface.

First, he changed the fifth parameter of a notification request on the REST interface to a series of named url parameters (url1, url2, and so on upwards), each containing the URL of a feed monitored by the cloud.

Next, he added a new ping format to contact cloud servers using REST.

Finally, he has proposed adding a sixth parameter to the notification request, but only for REST requests. The sixth parameter, called domain, identifies a server that will receive notification updates from the cloud server. It's an alternative to using the IP address for notifications.

Winer, the lead author of several versions of the RSS specification and one of the best-known authorities on syndication, is making these changes unilaterally.

Because RSSCloud has been a part of RSS for nine years, I thought it wise for the board to decide what, if anything, it should do regarding this effort. My personal belief is that it's extremely unwise to give a single developer the authority to revise this interface and author its specification.

Ideally, a group should decide what changes should be made to the next version of RSSCloud. This group could be the RSS Advisory Board, which deliberates in public and has 10 members from across the RSS development community, or it could be an ad-hoc group formed strictly to work on the effort.

As a member of the board for five years, I've had a lot of experience dealing with the consequences of a specification process that is closed to public participation and drafted with imprecise language. It leads to situations like the long-running battle over the enclosure element, which carries podcasting files and other multimedia over RSS. As described in the board's RSS Best Practices Profile, the RSS specification doesn't make clear whether an item can contain more than one enclosure. Developers disagree over what the specification means, so interoperability suffers as some allow more than one enclosure and others don't.

I realize that I'm tilting at windmills to suggest that Winer let the RSS Advisory Board get anywhere near the effort. Jon and Kate have a better chance of getting together. But as developers such as Mullenweg implement RSSCloud, they should insist that the revision process take place in public and involve a group of software developers and feed publishers who have the power to approve or reject each change. The group should write the specification together.

Letting Winer make all the decisions by fiat will just buy years of arguments over what his spec means and why no one should ever be allowed to change it.

According to PubSubHubbub developer Brad Fitzpatrick, Winer has said that RssCloud "is frozen and a 'done deal'."

Rss · Programming · Pubsub · 2009/09/15 · 9 COMMENTS · Link

Comments

It has often been said that the RSS V2.0 community considers its specification to be complete and not subject to modification. As I understand it, extensions to RSS are supposed to happen via defined extension mechanisms rather that adding to the existing spec. Thus, it seems to me that any modifications to elements defined in RSS V2.0 should be considered inappropriate.

Mr. Winer's modifications to rssCloud are sufficiently significant to be considered the creation an something entirely new (even though based on elements of the existing spec) -- certainly, they are more than mere clarifications of the existing spec. Thus, I would suggest that Mr. Winer be told that he really must cease and desist from using the name rssCloud to describe his new system and that he should create some new specification in which to describe his new system.

bob wyman

#1 · Bob Wyman · 2009/09/15

By now it should be perfectly clear that Dave Winer will say alomst anything, do almost anything to protect the legacy of his life's work:

RSS

Any threat to change, deprecate, obfuscate, or modify RSS without his approval is doomed to an internet food fight of monumental proportions.

Just step back and let him work his magic to maintain control, authority and influence over RSS and it's current offshoot: RSSCloud.

Dave cannot scale without the assistance of developers. The OPML Editor can serve as a testbed case for:
1. a realtime RSSCloud Publishing application (LiveFeed.org)
2. a Cloud "hub" rsscloud.org
3. a user reader/aggregator "River2"

It proves it all works together (if you are outside all firewalls... good luck with that).

Don't argue with Dave. Let the man continue to write his code and see more support.

The true value of a Hub/Cloud will be an internet scale service that works with readers that access it over port 80. Someone with a lot of capital will have to build it and then we'll test it for "realtime" latencies... ideally they will be able to make changes to the specs so other cloud/hubs can federate and extend the service horizontally (adding additional latency unfortunately) but making the case for a decentralizied realtime "twitter-like" service.

Roger's let the man have his spec back... you know the path to sanity lies on another road. Just take it or let a new cast of players get embroiled in the next iteration of the RSS Saga.

#2 · mcdtracy · 2009/09/16

"It's like deja vu all over again".

"Been there... couldn't do that." (Try not. Do.)

"Those who fail to learn from history..." (become programmers)

"All this has happened before, and all of it will happen again."
FTL jump

"What comes around..." Aikido

"You are in a maze of twisty little passages, all alike"
A hollow voice says "Plugh".
Try XYZZY

There is no game if you refuse to play.

#3 · mcdtracy · 2009/09/16

I don't know how to say this without sounding like I'm choosing "sides", but it doesn't matter. Really, it doesn't. I think you and the other folks on the RSS board (if I remember the membership correctly) are well-intentioned and generally do good work. But I think the crux of your argument is that you want a spec that is meticulous and impossible to misinterpret. While obviously that ideal can't be achieved, the PubSubHubbub community is more likely to yield the kind of spec that you're looking for, and in general has more of a process in place for getting your feedback.

At the same time, Dave's doing useful work on RSSCloud that, I'm sure, can be construed as unilateral. While I do know he's listening to some folks for feedback, my (admittedly minor) knowledge of the past relationship between you both leads me to believe it's unlikely you'll be one of the people providing feedback to Dave that is seen as constructive.

Here's what I know: Almost nobody has used RSSCloud since its initial deployments at the beginning of the decade. There's certainly no mission-critical implementations that are going to be disrupted by any current evolution of RSSCloud, and I'm sure if I'm wrong and one of the new features breaks something, that'll get fixed.

But overall, you seem to be focused on tilting at a windmill that I think 1. is only going to lead to you being frustrated and 2. has the chance of igniting yet another stupid syndication flamewar, even though that's not your intent. While Brad and Brett did the early parts of their PSHB development largely on their own, they're all ears now.

My suggestion? If you're trying to improve the realtime feed tech specs that get adopted in the real world and want to have a say in making sure they're correct, give Brad and Brett your feedback and I am certain every reasonable request will be accommodated. If you have a n example of how the current development/evolution on RSSCloud breaks something in the RSS feeds that have been developed over the past 10 years, by all means let everybody know.

But if you just want Dave to not be in charge of the current work on RSSCloud? Not gonna happen, and not even a worthwhile goal. There's a format for people that want IETF-grade specs, and there's a format for people who want simple, human-readable but potentially ambiguous specs. You are trying to put a saddle on a cow and lamenting that it doesn't ride like a horse. Either switch animals, or learn to appreciate milk.

#4 · Anil · 2009/09/16

I appreciate the feedback.

Since the RSS Advisory Board went public in 2006, we've avoided fights where we could find more constructive ground. We didn't revise the RSS specification to make it clear on issues like enclosures, the position that I originally favored. Instead, we wrote the RSS Best Practices Profile so that implementers could do the best they could with RSS as it existed.

I don't know what the board wants to do here. On the one hand the RSSCloud Interface is part of the specification, and our position is that any change to it requires a vote of the board. On the other, it was dead. I'm not aware of any significant implementations other than Radio UserLand and possibly Manila, and UserLand shut down its cloud servers years ago.

My hope in writing this is to persuade Matt Mullenweg and the other developers who implement the new RSSCloud to work together on the specification and produce it through some kind of public voting process that's accountable. It isn't to dictate who should lead that effort.

I'm not seeking a personal role in the effort. I do not share your opinion that there is value in "potentially ambiguous" specs. I've seen that movie before.

#5 · Rogers Cadenhead · 2009/09/16

Cooool. My favorite soap opera has been renewed!

#6 · Tim · 2009/09/18

You should bang your gavel and end this little experiment of Winer's. Maybe send him a bill for wasting so much of your time.

#7 · Lawrence Krubner · 2009/10/06

Or as Mark Pilgrim once said:

"RSS 2.0 is not "frozen". It has never been "frozen". It has been capriciously and backwardly incompatibly changed multiple times without community involvement or discussion. Examples that were in the original version have been silently removed when their existence was deemed politically inconvenient. Exactly one man (who, ironically enough, claims not to "control" RSS) has been responsible for all of these changes."

Back in 2006 I wrote a history of this particular soap opera:

www.teamlalala.com

Perhaps it will have a new chapter?

#8 · Lawrence Krubner · 2009/10/06

And doesn't it seem likely that Winer will once again announce that the RSS Advisory Board does not exist? I recall your reaction last time he announced that the group didn't exist:

"As a member of the RSS Advisory Board for the past 21 months and the current chair, I am surprised to learn that the organization doesn't exist. I joined the board at Winer's invitation in May 2004, not long before he resigned. The group operated in private without a charter, and as I said at the time, the reason I joined was to help guide Really Simple Syndication to a public, participatory model like that enjoyed by Atom and RDF Site Summary (a.k.a. RSS 1.0)."

And then he hit you with a lawsuit over what was nominally an unrelated matter, though of course, everyone understood the connection.

#9 · Lawrence Krubner · 2009/10/06