Re: Removal (Time for XMail?)

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