- From: Laird Popkin <laird@io.com>
- Date: Sat, 28 Oct 2000 00:34:21 -0400
- To: "Aaron Swartz" <aswartz@swartzfam.com>, "David Orchard" <orchard@pacificspirit.com>, "'XML-DIST-APP'" <xml-dist-app@w3.org>
- Cc: <ice-ag@egroups.com>
Comments below: -----Original Message----- From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On Behalf Of Aaron Swartz Sent: Sunday, October 01, 2000 11:41 PM To: David Orchard; 'XML-DIST-APP' Subject: Re: Removal (Time for XMail?) David Orchard <orchard@pacificspirit.com> wrote: There's a definite need for a spec to allow people to send URIs over the Web. I'm working on this with the changedPage spec -- basically a way to put up a page on the Web, which will take notifications (as form-data/CGI-style input) a URI. The understanding is that this URI has been updated, and your application should go ahead and take a look at it. (Obviously, all sorts of meaning can be then layered on top of this, etc.) This is the serious limitation of the HTTP pull system -- there are no "triggers" -- no way to see when something has changed or updated or added without checking it repeatedly. This problem has come up a lot in RSS (http://www.egroups.com/group/rss-dev) with RSS aggregators constantly pulling the same RSS file every 15 minutes, even if it hasn't changed. A lot of bandwidth waste. ---- Yep, and there is a spec for allowing people to send URI's over the web. ICE (see http://www.icestandard.org) has both push and pull content syndication for this reason. In my opinion, for most applications "push on change" is most efficient, though "regular pull" is easier to implement (e.g. cron job calls ICE client command-line tool to check for an update, server checks for changes). I'd suggest for your application that you look at ICE as a reference point, specifically at the idea of using push delivery of ice-item-ref's. It's becoming fairly common to use ICE messages to transmit the metadata related to an update, with the subscriber then retrieving the content via HTTP/FTP. I don't know if the semantics of content distribution is too specific a topic for the xml-dist-apps list. If so, someone should say so... ---- A push system (ignoring all the negativity/hype/press of Pointcast and friends) definitely has its advantages, as seen by the popularity of email/listservs (push) as opposed to newsgroups (pull). Many people don't have the time to go and check the thousands of websites out there that they're interested in. Instead, they'd rather be notified when something of interest comes up. ---- It's interesting to consider the meaning of push/pull at both the protocol and the user interface layers. At the protocol level, mail (POP, IMAP), news (NNTP client-server), the web, etc., are all pull. Indeed, so are nearly all of the "push" mechanisms. This is probably due to the fact that most of those protocols are designed around the assumption that the communications are initiated by a client that is only intermittently running (e.g. a mail client) so it's not possible for the sender to actually initiate communications. ICE is designed as a business-to-business protocol (like SMTP, and NNTP server-to-server) so it's "push" delivery mode allows the content sender to initiate the protocol. This eliminates the inefficiency of polling, of course. At the user interface level, however, more protocols "feel like" push. Email, for example, arrives automatically. It's possible to act like push while using polling as the underlying mechanism: Marimba, email, ICE in "scheduled pull" delivery, and so on all do this. The attempts at allowing web clients to subscribe to web sites, the most successful of which is probably AvantGo, are an interesting attempt in this direction of building a "push" experience on top of a "pull" protocol. I suppose that you could think of a computer running sendmail, but on which you only occasionally run an email client to actually check for mail, as an example of the inverse -- true push delivery with a "pull" user experience. The reason that I'm bringing this up is that the two levels are relatively independent. The advantage of acting like push to the user is that they don't have to do anything -- information just shows up. The advantage of push at the protocol level is that it's far more efficient, and delivers information as rapidly as possible, at the cost of requiring receivers to be persistent. Given all of the various possibilities, I'm curious which combinations are most interesting to you? ---- Sorry, getting a bit wordy, but I hope I get the point across. I think this is definitely an interesting application/possibility/space for XML-DIST-APPs. -- Aaron Swartz |"This information is top security. <http://swartzfam.com/aaron/>| When you have read it, destroy yourself." <http://www.theinfo.org/> | - Marshall McLuhan
Received on Monday, 2 October 2000 00:39:54 UTC