While I'm showered with gifts for Kit, someone's mailed me with a couple deficiencies with it. Not intentionally, I mean, but in the same mindset that has folks ask for a preference instead of demand a bug be fixed. These are bugs, and there're reasons they're there, but I aspire to fixing them.
- Search only works locally. I'd love for full peers to handle searches from their public web site, but I'm not sure how to set that up. Perhaps I'd also want to use a less naïve algorithm. Perhaps I should let search-specific services handle it. This is actually a pretty intractable problem from my perspective.
- Search should all searching by category.
- Radio to the Future is opaque. You can't post future items now.
Then there are Phil Wolff's klogger-oriented requests, mentioned yesterday.
- "1. Support the blogging of other objects besides a post" and "5. Rework the Radio Outliner's user experience from scratch" strike me as opportunities for a light client to be written from scratch. #1 would require changing the post process scripts to handle nontext items--that's definitely an assumption that's been there, so dropping that would be hard. A simple, general system could leap ahead here. Similarly, the outliner is central to Radio, so I don't see UserLand breaking it in that way.
- I'm sure Phil would point out in "2. Better news reading for scale, efficiency, and smarts" he means a general revamp of the news display system, but starting from Kit as I am, I see a set of tweaks and changes to make. "Meme tracking" would be a big step: you could link "Posts that cite each other" by what items link to what item's permalink, but it's not possible to find most items' permalinks.
- #3 and #4 don't concern me. The following are from the lesser 30.
- "7. Run selective RSS feeds through Google's API for the translation." Phil's contextual link on this is about publishing translated feeds, but from context I was thinking doing it on the aggregation end. Of course it'd be better to have a translated feed, since that only uses the author's search quota.
- "9. Include permalinks in syndicated body." Kit will have an option to publish your weblog's RSS feed using your item template; that would put the permalink and your comments link in the item's body. (Unfortunately it will also duplicate your titles, but that should look OK in other aggregators besides Radio, I guess?) I imagine UserLand may add a feature like the new "(comments)" link that exhibits items' permalinks through the RSS 2.0 guid element, but since Radio doesn't know how to calculate my real permalinks, I'm in a tight spot.
- "10. Linkrot spider, reporter, and healer." That would be nice. Maybe automatically check all the links from one week, one month, six months, and a year ago. Prior art includes Tulip Chain, for Open Directory Project editors.
- "12. More than one multi-authored synthetic category per Radio" is a current concern. Phil's link talks about inputs and outputs, so I start thinking of Reason, the "virtual studio rack" that lets you stick boxes together with virtual patch cable. A solution based on that would be more general than just multi-author weblogs.
- "14. Backlinking" suffers the same problem as search: it requires an Internet-accessible component. Sure, it's possible, but it tends to let me out of doing it.
- "19. Show and let me manage the publishing queue. (like a print queue)" would require rearchitecting bits like big wishes #1 and #5. Radio doesn't actually have a publishing queue: it has an item list, and sometimes the top items of the list aren't published to the public site yet. If I were to do it, I would do it in the same way as I did Kit's Radio to the Past, having a separate list of items that eventually get posted to Radio's item list.
- "21. Secure blogs." Radio still supports HTTP authentication. Macrobyte has SSL client software, but HTTPS would require changes to tcp.httpClient.
- "30. Continuous writing (autosave to web)" could be done with JavaScript but wouldn't make a lot of sense without a publishing queue (#19).
