2006-04-15
The problem of the growth of syndication feeds
Sam Ruby has a problem: he has too many feeds. Specifically, he has a comment feed for every blog entry, and too many robots and abandoned aggregators are pulling them, over and over again, despite the feeds effectively being dead. (See his entry for his solution.)
Sam Ruby isn't alone in having this problem; anyone with a lot of flexible
syndication feeds is going to encounter it sooner or later. (Even if you have only a few human
readers, some search robots love syndication feeds. Even if you try to
tell them to bugger off via nofollow et
al.)
The more I've thought about this, the more I think that it's actually a social issue: we're so early in the syndication revolution that everyone is still figuring out how to organize things. Over time all of this will get solved; we'll work out what feeds are useful, users will form definite expectations of how sane feeds are organized, and there'll be 'good feed reader seal of approval' (social) standards for how polite feed readers should behave.
Some of this development will be technical, such as figuring out how to mark comments in feeds to clearly group conversation threads and link them to parent articles (there is a 'Feed Thread' draft RFC in progress, eg here). And anything that automatically mass-pulls syndication feeds is going to need to get much smarter about detecting overlapping feeds. (Failure to get smarter will result in mass lynchings.)
WanderingThoughts avoids some of these problems because I decided that the auto-discoverable feed for an entry should be the main feed rather than comments on the entry. While each entry does have a comments feed, people have to feed it to their aggregator more or less by hand, and the same holds for the various aggregated comments feeds. (In theory you can have several autodiscoverable feeds on a page, but I don't know if anyone handles that well yet.)
For annoying spiders that like to crawl my syndication feeds, I now use a blunt hammer; selected user agents get 403 responses on all requests for syndication feeds. I am optimistic that they will someday take the hint.
Public interfaces and Solaris 9 patchadd exit codes
A commenter on an earlier entry noted that
patchadd's exit codes are apparently not documented because they're
considered an internal implementation detail that might change at some
point. Unfortunately this is bogus logic.
There's a simple rule: once you explicitly expose something to users, it
ceases to be an internal implementation detail in practice no matter
what you want (and no matter what you may claim in documentation,
although Sun does not explicitly claim this in the patchadd manpage).
Solaris 9 manifestly exposes patchadd's exit codes, since they are
reported as is by things like the Solaris 9 recommended patch cluster
installation script, as I found out. If Sun
wanted system administrators to remain blithely ignorant of patchadd's
fine details, all of the higher level tools should have hidden them; as
it is, we won't be very happy if Sun were to turn, eg, 'return code 2'
from something harmless to something that indicated a real problem.
I consider exposing things to people different from exposing them to programs. It's very hard to hide internal details from programs that go poking, but it's a quite different thing to shove those details under people's noses. And once you do the latter, you lose grounds to complain about programs using the information too. (In effect the programs have stopped being nosy parkers and have become our agents.)
(Disclaimer: I don't know if Sun really considers Solaris 9 patchadd
exit codes to be just an implementation detail. The manpage doesn't
document them, but then it doesn't say that they're private. Besides, it
just makes a convenient example; the attitude is unfortunately somewhat
generic.)