Continuing with codecasting
Sunday, February 18, 2007 by Dave Winer.
Two changes to how the feed is generated. 1. Only output a part once, no need to update a part more than once, when updating, the last version will overwrite all previous versions. 2. Because of the first change, we have to change the order of the feed to reverse-chronologic. The result of this changes is that the size of the feed decreases, and the time spent processing it on updating decreases, and the cost of running the server decreases. A three-way win, so an obvious improvement. 
If all goes well, I'll release the client code to OPML Editor users. It won't be turned on by default, but I will turn it on in all my copies of the OPML Editor, so it can get a good test before deploying to user sites.
People ask what's so great about codecasting, and the answer is, for users, nothing in particular. For developers who manage environments with users who need to update frequently, it might cut the cost of providing updates. For me, it certainly will cut my costs, and since the software that I will update is open source, and produces no revenue, cutting costs means I have more money to go to the movies, eat out, buy toys, pay for health insurance, save for retirement, give to good causes. I write about stuff on my blog because I like to keep a record of my work, so it may not make sense to you, or even seem like a good idea, if so, so be it.
Actually, there is an advantage for users. The current method of updating requires the user's app to call teh server on port 5337, but we've received complaints that some corporate firewalls don't allow traffic on that port (contradicting the assumption, btw, that some critics of XML-RPC offer, saying we're just tunneling over port 80). Using RSS and a plain old web server, now we really are doing updates on port 80 and the corporate firewalls won't have any issues with it. 
Another reason I document my work here is so that I can include pointers in my comments, saving me having to document my work twice.
