I’ve been looking for a while for an RSS to XML-RPC routing service that would in effect relay content from one site to another. If anyone has seen such a service please let me know.
Basically you’d log into the service, add in RSS feeds (mix multiple ones together even) and then select an XML-RPC method (such as MetaWeblog API) to relay and post these feeds onto another site. The amazing thing is that this service would really only need to relay the feed content, not store it.
Why am I looking for this? Because it would alleviate the need for blogging services to include feed aggregation within their services itself.
How would I use this? To create my Connected Communities idea. In effect, allowing many individual local sites to collaborate together on a collective effort through the sharing of information.
6 replies on “Idea for RSS > XML-RPC Web 2.0 Service”
I hope to understand: try http://www.newsgator.com. You add the feed you want, and then, they give you a code, or an email, that you can insert in your html page that shouw all the feed you’ve subscribed in your blog.
Is that ok?
Actually a lot services already offer what you describe. For example, the RSS-To-Javascript site below allows you to enter in an RSS feed then paste Javascript on your site to display this feed on your site.
http://www.rss-to-javascript.com/
What I’m referring to is a service that takes the feed and automatically posts it into the blog journal on your site via an XML-RPC blogging client interface (and continually does so when new feeds are added). In effect, the full contents of the feed are actually being transferred into your blog journal which means all of the previous feed information is accessible on your site, since it is being aggregated / collected.
With the RSS-To-Javascript approach, this only displays the latest feeds on your site. They aren’t actually integrated into your journal and thus you can only see the latest feeds, not previous ones (unless you visit the source of the RSS feed).
While I’ve never looked into it in depth, http://outputthis.org/ sprung to mind, however, after looking at it now, it doesn’t appear to do as you ask for users, only developers.
Still, I feel uneasy with this idea in the long-term. I don’t believe that simply creating a planet feed aggregator to XML-RPC publishing protocol goes far enough. What happens if users want to edit a post aggregated to a second site they’ve created, edit at that site? The original then becomes outdated unless there’s a mechanism to alert/update the original. I personally don’t like the single interface, then aggregate publication mentality. I want to be able to move my data around and edit it from anywhere. Not to mention store it where I chose and access that store from anywhere…
A much better way in my mind is to poll and push/pull content periodically if permissions permit. Technology like SSE is doing something along the lines of polling (have to read the spec again, but don’t like it because its RSS and the limitations that come with that).
I’ve been thinking about this space a bit. Another emerging idea is LLUP (PULL) that M. David Peterson is working on. I’m just getting my head around it but I see something like this coupled with the Atom Publishing Protocol and something along the lines of Live Clipboard and microformats/RDFa as potentially being a much better solution for the future. There’s also <a href="http://cometd.com/">cometd</a> for browsers to take into consideration as to where things are headed. Think of a widget on the client that polls for the latest updates using cometd, aggregates and presents that data in your browser. Be it a chat client/server relationship or a feed reader to aggregator relationship. Your blog(s) will eventually become a widgets. Every single piece of content you create will probably go into a secure ATOM feed (your content creation history) as an entry with relevant metadata about that object with it. Anyone with permission could then copy and paste that object data (image/video/text) into their page and maintain that metadata relationship(privacy, copyright, etc). Update that object and the original changes with a revision and any sites referencing that object get the updated one should they have chosen to in the link contract.
RSS > XML-RPC doesn’t get me here.
My view is that in the not-too-distant-future I’ll be living in a Live Clipboard(like) identity connected community with all this polling happening in the background.
And after that… a Secondlife that is actually usable incorperating these features and more.
Then a virtual reality interactive version of this.
Then, the real world. lol. Cybernet(ics).
Ok Nollind, sorry to be Off Topic
Valerio: No problem at all. You were on topic, I’m justing looking for something that takes the "next step" if you will. 🙂
Craig: "What happens if users want to edit a post aggregated to a second site they’ve created, edit at that site?"
Totally depends upon how the routing works. You can edit posts with XML-RPC and depending upon how the system detects and reads the RSS feed, it can detect the change and thus possible make the change.
"I want to be able to move my data around and edit it from anywhere."
This actually doesn’t have to with the "portability" of your content but more how easily it can be shared and mirrored with others. Hmm, or put it this way, it has nothing to do with the "structure" of your content (remember the stuff I chatted about before) but how your content can be shared everywhere (i.e. the information everywhere concept).
"RSS > XML-RPC doesn’t get me here."
RSS > XML-RPC is a cludge to achieve some of this information here and now with existing technologies. Is it the idea solution? No way. Not by a long shot. It is a usable method for just "relaying" information though. In effect, it’s a start. I’d rather that every blogging service incorporated RSS aggregation within them but that’s still going to take a while. I’m just looking for a shortcut right now though, that’s all. 🙂
"RSS > XML-RPC is a cludge to achieve some of this information here and now with existing technologies."
If you build it they will come. I’m sure many would use such an intermediary service.