It’s just data

Blogging tools ecosystem

SharpReader is currently a monolithic application.  I'd like to see it interact with the ecosystem a bit more.

There are two ways to approach this.  One is the monolithic application with components model.  Somebody identifies either the dll or assembly to be invoked when a given event occurs.  This is probably the way to handle the pluggable browser request.

The other is more peer to peer from an application perspective.  You accept requests over a socket.  You send requests over a socket.  Simple example: allow people to add rss feeds to the aggregator.  Another example: allow people to configure a userid, password, and URL to be POSTed to when the subscriptions change, and I can write a CGI which will update my blogroll.

I see Luke uses Movable Type.  Wouldn't it be handy if MT users could click on an icon and have the MT dialog launched with the entry field prefilled with the relevant blogroll item blockquoted?

I posted some thoughts about adding a blogThis extension point to RSS readers yesterday

Posted by Simon Fell at

Simon, I must confess that your post inspired mine... I don't think that an aggregator to RESTLog API would be the right thing to do... typically one wants to insert some value add in the process.

That got me to thinking about an aggregator to weblog authoring tool API...

Posted by Sam Ruby at

Right, in that case the plug-in would popup some UI to edit the post before sending it on, along the lines of what Radio & NetNewsWire does.

Of course you could easily replace/augment my CLR based interface for a xml/sockets interface.

I need to make a clearer description of what I am thinking, I have it all laid out in my head, just need to work out how to describe it properly.

Posted by Simon Fell at

Simon, Radio does it with a socket interface.  A fairly RESTful one at that.

If XML is introduced, consider for a moment what data a typical aggregator has around.  What would be the obvious representation for that data?

Posted by Sam Ruby at

In my CLR based thought, I was running with the idea that when the user clicks "blog this" on a post, it passes the RSS fragement for that post to the plug-in. The plug-in can then pre-poulate its own editing UI and handle creating the new post.

This conviently maps to a sockets interface as well, and has the advantage of not being tied to .NET

Posted by Simon Fell at

Listening for new feeds

Sam Ruby was talking about Blogging and a tools Eco System. I was interested in the bit about listening locally for new feeds so I implemented a quick piece of Java to do it. URLs look like...

Excerpt from blog(f00) at

Maybe I'm underthinking this, but the interface that would work best for me would be to tell SharpReader that I'm using MT, at, and have it GET mt.cgi?is_bm=1

After all, we've got an embedded browser right there, and supporting an extension (like the keywords field, which might be supported by the MT API, but isn't documented) becomes just a matter of adding another word to bm_show.

Posted by Phil Ringnalda at

Awasu is highly extensible and already does what you mention. Scripts can be written to extract information from somewhere (e.g. a database or a running application) and generate an RSS feed for it. Then, more scripts can be written that get invoked when things happen on a channel (e.g. it is updated or new items are found).

The 1.0.2 beta includes samples that generates a feed from rows in a database and sends emails when new items are received.

Posted by Awasu at

Phil - if a tool independent interface were made, how hard would it be to write a new cgi which parsed the parameters and then called the existing mt.cgi?

Posted by Sam Ruby at

Dead simple, especially since I already need to write one that takes a comment encoded as RSS and passes it to the MT comment cgi (sorry, skipping a step to what the independent interface will be).

But what should I tell my friends with nothing but a blog on Blog*Spot to do?

Posted by Phil Ringnalda at


I should of gone to bed, instead I started looking at the Synderilla code to prototype up my blog this extensibility point idea. I have the extensibility point working, although the plug-in does nothing more interesting than message box the XML, but...

Excerpt from Simon Fell at

Phil: switch?  ;-)

Seriously, if the server isn't extendable, then some more code needs to be written on the client.  It can run in a separate process (like Radio), or in the same process (like Simon is exploring).

I'd like to see an approach where multiple clients and multiple servers can be supported.  Where there focus is a common extensible base that everyone can deal with (RSS item), coupled with a means by which application specific parameters can be dealt with in a way that the producer can mark the items as important or not (i.e., headers).

Posted by Sam Ruby at

Source of ideas

Sam is really a source of ideas related to RSS. Many of my own thoughts regain on his blog, so I do not have to scribble down all the stuff again ;-) just read the blog again. Hints about the BCL type names are important to me if I have to design...

Excerpt from torstens .NET blog at


Cool, its gaining some interest. There's pushback on the use of XML, which i can understand, I was trying to stay with XML to run with something similar to what Sam is thinking about, How does this grab you ? interface IWeblog { string Name() ; Uri...

Excerpt from Simon Fell at

Add your comment