This means that even for polling, you're not wasting resources being polled all night. Rssowl activity update#ICE also has a scheduling mechanism, so you can tell a subscriber exactly how often you update (e.g. For example, rather than responding to 99% of updates with "here are the same ten stories I sent you last time" you can reply with a tiny "no new stories" message. This means that the updates that are transmitted are far more efficient. ICE supports incremental updates, so the syndicator can send only the new or changed information. Push means that there are many fewer updates transmitted, and that the updates that are sent are more timely. And while many home users are behind NAT, web sites aren't, and web sites generate tons of syndication traffic that could be handled way more efficiently by ICE. This eliminates all of the "check every hour" that crushes RSS syndicators. So if the network allows for true push, the syndicator can push the updates, which is most efficient. the syndicator and subscriber can negotiate whether to push or pull the content. The short version is that ICE is far more bandwidth efficient than RSS because: The ICE syndication protocol has solved this. The result of this would be a system that could scale to just about any size, easily.Īnybody want to write it? (Unfortunately, my time is TAPPED!) Wash, rinse, repeat until the subscription is accepted. The client requests subscription to the service, and the request is either accepted or deferred. Whereupon the process starts all over again. It either accepts the request, or redirects the client to one its already set up clients. In other words, a client makes a request to be added to the update pool on the root RSS server. Because of the certificate used in #1, this could be done easily while still ensuring that the content came from the "real" source.ģ) Subscription to the RSS feed could be done on a "hand-off" basis. It should be encrypted with a certificate so that clients can be sure they're getting content from the "right" server.Ģ) Any RSS client should also be able to act as a server, NTP style. Also, there's no effective way to mirror content.ġ) Content should be pushed from the source, so only *necessary* traffic is generated. The basic problem with RSS is that it's a "pull" method - RSS clients have to make periodic requests "just to see". (Or maybe I'm bitter because the weird intraday format that emerged for my own site doesn't really lend itself to RSS-ification.) I kind of admit to not really grokking RSS, for me, the presentation is too much of the total package. However, in today's heavily firewall'd internet, I dunno if that would work so well, especially for home users. (Wired had an interesting retrospective on their infamous "PUSH IS THE FUTURE" hand cover about PointCast.) And that's expensive, the cyber equivalent of a hoarde of screaming children asking "Are we there yet? Are we there yet? How about now? Are we there yet now? Are we there yet?" It would be good if we had an equally widely used "true Push" standard, where remote clients would register as listeners, and then the server can actually publish new content to the remote sites. "Despite 'only' being XML, RSS is the driving force fulfilling the Web's original promise: making the Web useful in an exciting, real-time way."Įrr, did I miss the meeting where that was declared as the Web's original promise?Īnyway, the trouble is pretty obvious: RSS is just a polling mechanism to do fakey Push.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |