- From: Kurt Cagle <cagle@olywa.net>
- Date: Mon, 2 Oct 2000 01:49:15 -0700
- To: "Laird Popkin" <laird@io.com>, "Aaron Swartz" <aswartz@swartzfam.com>, "David Orchard" <orchard@pacificspirit.com>, "'XML-DIST-APP'" <xml-dist-app@w3.org>
- Cc: <ice-ag@egroups.com>
I've been exploring a SOAP based XHTML client app, and found the push/pull references here interesting. It does occur to me that you can use scheduled asynchronicity as a push method. In this, the client transmits a message requesting an initial download. The server returns this information, but also returns the current timestamp and a second timestamp that indicates the time of the next update. The client then forks this second timestamp to make a call at the indicated time. This obviously only works with material that is updated on a regular basis (or with scheduled material), but it dramatically reduces polling on the part of the client. This method would actually work well with applications that let you schedule content. I don't see avoiding polling entirely -- especially in the latter case -- but the amount of polling would drop considerably. It's late, I'm stating the obvious, and I'm going to bed. -- Kurt Cagle ----- Original Message ----- From: "Laird Popkin" <laird@io.com> To: "Aaron Swartz" <aswartz@swartzfam.com>; "David Orchard" <orchard@pacificspirit.com>; "'XML-DIST-APP'" <xml-dist-app@w3.org> Cc: <ice-ag@egroups.com> Sent: Friday, October 27, 2000 9:34 PM Subject: RE: Removal (Time for XMail?) > 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 04:52:52 UTC