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?
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...
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
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...
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 philringnalda.com/mt/mt.cgi, and have it GET mt.cgi?is_bm=1
&bm_show=trackback,category,excerpt,text_more
&__mode=view&_type=entry&link_title=...&link_href=...&text=...
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.
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.
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?
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?
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...
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).
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...
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...