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 00:39:54 UTC