FeedTree misconceptions.
Elsewhere on the Interthing there’s some concern that because FeedTree moves feeds away from a polling architecture to one of on-demand notification, it takes away control from the user:
Mm, one last things. Several people have noted how happy they are that FeedTree can turn RSS from a push to a pull mechansim. I don’t like that concept. I like RSS for its meta-data, and for the control I’m afforded because I have complete control over it. “Push??? the content and you take that away from me. Want push? Just get email updates. Setup your filters to organzie and categorize your emails. Ta da, instant, existing, pretty dang easy push system. :/
I assume that the “control” the author’s worried about losing is control over unsubscription, and if so, this is a very legitimate concern—even for email.
The fundamental problem with push-by-email is that your email address acts like a capability: by giving out your address, you offer someone the irrevocable ability to spam you. You must trust that the other side will never share your address, and will honor any unsubscription request. (As an aside, this is one of many reasons that email is becoming less popular as an interpersonal communication medium; the signal-noise ratio is so low—thanks to spam, mailing lists, and email update services—that many are abandoning it in favor of IM and SMS. Unfortunately, these services suffer most of the same capability-related access control weaknesses, and so it’s only a matter of time before these channels also become polluted.) Throwaway email addresses are one simple way to address the irrevocable-capability problem with email, but they’re hardly user-friendly and are not available to all users.
Feeds, on the other hand, solve this problem by retaining control over subscription locally, rather than deferring that control to outside parties. You can always unsubscribe to a feed: just stop polling it. It’s crucial to observe that FeedTree works exactly the same way. You can always unsubscribe to any feed whose updates are pushed via FeedTree; your local client will cease to receive updates via the Scribe multicast system. (Even if a malicious entity attempts to assault you with updates after you’ve unsubscribed, or updates for a topic which you’ve never been interested in, the Scribe framework will ignore these uninteresting messages.) In short, FeedTree’s “push” service model does nothing to reduce your control over which feeds you see.
The author has other harsh words for the FeedTree research project—most of which are, in my opinion, undeserved. His chief complaint is that all Web feed bandwidth issues are 100% solved by conditional HTTP GET (ETag/If-None-Match and If-Modified-Since). Conditional GET is hugely important for polling clients, but it’s hardly sufficient: if a feed changes frequently (many popular ones do), or has any dynamic content (read: advertisements, becoming increasingly common), this protocol breaks down and the entire feed is always transferred.
There are other aspects of the article which I disagree with, but these are the key areas in which I feel the author misunderstands both the architectural problems inherent in RSS and the way FeedTree intends to address them. As with all academic research projects in the field computer systems, FeedTree is a part of a larger discussion about how technology can be made more efficient, more powerful, and more usable. I welcome the debate.