The purpose of this entry is three fold. As you may know from the old adage, a person's "doing mode" and his "complaining mode" are mutually exclusive. My previous entry was probably interpreted as a complaint, even though my main intention was to philosophically discuss a certain pattern with online, public wikis. I admit it had an element of a rant in it, but that was not the main point. However, most of the other posts, were nothing except complaints, which kind-of-saddened me.
Well, I decided to do something about the original motivation for the post. After waking up early (not by purpose), I placed the problematic section on the wiki, and discussed it interactively with the (mostly Australian) editors of perl.net.au on IRC. Together we have reached a phrasing that we were both (more-or-less) happy with it, and decided to keep it there. So that was a "doing".
I still think this solution is not always applicable. perl.net.au is still relatively small, and trying to do that for an international wiki the scope of the English wikipedia, where there's much more red-tape is going to be much harder. This is one reason I think MediaWiki needs better ways to manage threaded conversations, with good interface controls.
The second issue is that I also Israel.pm'ed and KansasCity.pm'ed a few IRC conversations I found amusing. You can comment about them here, in the not-entirely-unlikely situation that you have something to say.
The third issue is that I'm trying to get myself to write a specification for a client/server protocol for a web feed reader. As you may know, there are web-based readers, but their interfaces tend to suck, and they are not as convenient as GUI ones. Now, I've been thinking of having a remote server for storing the feeds' collection, and any number of clients (that could be a web application or a GUI client or anything else you want), that will interact with it, login there and manage the feeds. This is similar to the what the IMAP Protocol is for email only for web feeds. The state of all the feeds is maintained on the server, so you can access it from any where.
I'd like to start working on a functional spec and technical spec for the protocol. I'd like to start with something very basic and with many perlisms , but enough to raise some interest. So far the people I told them about it either thought it was a great idea, or alternatively gave me motivational complaints, which indicated they could not understand why it would be useful.
Re: Feed APIs (Score:1)
http://decafbad.com/blog/2007/04/29/say-hello-to-feedmagick2 [decafbad.com]
http://search.cpan.org/dist/WebService-Bloglines/ [cpan.org]
http://www.newsgator.com/ngs/api/ [newsgator.com]
(darren)
Re: (Score:2)
Hi dlc! Sorry for the late response.
http://decafbad.com/blog/2007/04/29/say-hello-to-feedmagick2 [decafbad.com]
http://search.cpan.org/dist/WebService-Bloglines/ [cpan.org]
http://www.newsgator.com/ngs/api/ [newsgator.com]
Wow! Cool. That seems like exactly what I wanted to have. Thanks!
Of course, the first link makes a bad impression due to the fact it's just a blog entry, and I could not understand what it's about (as blog entries go). As for the second link, Bloglines was dead-on-arrival for me when I tried it. [livejournal.com]. NewsGator was the web feeds' web-based reader of choice of a hacker friend of mine, and she said she's very happy with, so I'll take a look. I had an OK-to-relatively-b
Re: (Score:1)
XML-RPC Aggregator API (Score:1)