Bill Seitz writes:
But I wonder whether it makes more sense to transport the full content, so that the reader can do some background BlogWeb processing, even if it only displays a truncated description. For instance, the reader could assign a blogbit to a reader-defined category based on matching keywords anywhere in the content. [ WebSeitzWiki ]
Yes, that's the flip side of the coin. If you knew that readers could reliably trim inbound items, you might want to make sure everything gets sent. The answer here partly depends on how soon you think we'll be living in a pervasive data cloud that makes replication less necessary than it historically has been. If you knew you could always get to the content through its link, and process it however you like, you'd care less about having it local.
Short-term (i.e. next decade) there will be many reasons to replicate. So here's another variation on the theme. Use your RSS writer's truncator not to omit outbound content, but only to suggest a boundary between the body (sent as RSS description) and the full item (sent as RSS enclosure). A reader could use, or ignore, this rendering hint.
We desperately need something like this in email. The email UI is sadly non-scannable: titles (often useless), and no blurbs. The reason email can't do what we're here imagining that blogs can do: it doesn't produce canonically URL-addressable content. Blogging produces such URLs as a matter of course. That's one reason it may become the laboratory in which email gets reinvented.
Former URL: http://weblog.infoworld.com/udell/2002/03/19.html#a150