Re: [syndication] SOAP meets RSS

["Dave Winer" <dave@userland.com>]

Mark, the problem we're solving is the inverse of the one you are taking on.

You're wanting to make the current browsing experience better.

We're trying to change the browsing experience so that the click-and-wait
effect goes away.

Both activities happen in the Web browser, but that's all they have in
common.

Both threads are worth pursuing, imho.

That said, we will have a cache on the local users' hard drive, independent
of the browser (but accessed through the browser) and that cache can benefit
from an invalidation protocol/format.

Dave


----- Original Message -----
From: "Mark Nottingham" <mnot@mnot.net>
To: <syndication@egroups.com>
Cc: "Radio Userland" <radio-userland@egroups.com>
Sent: Sunday, January 07, 2001 10:09 PM
Subject: Re: [syndication] SOAP meets RSS


>
> Hey Dave,
>
> You might be interested in one of the proposed work items for the
> IETF's WEBI working group (aka WREC) - we just had our first meeting
> in San Diego.
>
> Basically, there are a lot of people in the caching industry who are
> interested in an invalidation protocol. However, as others have
> mentioned, it can/should be defined as a more general problem -
> subscribing to a channel on which updates/invalidations/whatever are
> sent, pertaining to a particular resource or group of resources.
>
> I'd encourage you and anyone else interested to have a look at the
> presentation -
>   http://www.mnot.net/papers/ietf-49-wrec.{ppt|pdf|htm}
>
> and join the mailing list -
>   webi-request@lists.equinix.com
> (majordomo)
>
> We're just about to start discussing the work items and gathering
> requirements, so it's a perfect time to have a say. We're also
> looking for document editors, etc.
>
> Cheers
>
>
> On Sat, Jan 06, 2001 at 08:50:21AM -0800, Dave Winer wrote:
> > Thanks Dan..
> >
> > Hammering-avoidance is very much on my mind as our servers are getting
> > pounded by search engine crawlers in vast numbers and always at the
worst
> > possible time. At the same time we're experiencing substantial growth in
our
> > free Manila hosting service, and money is a big issue (as it is
everywhere
> > these days it seems).
> >
> > In that context, we designed this system so that:
> >
> > 1. Most bits are served statically.
> >
> > 2. The reliance on SOAP/XML-RPC is limited to smallish messages, usually
> > with just a few scalars and possibly an array. These travel over the
wire,
> > even for people with relatively slow lines (like me), very quickly.
> >
> > 3. As much as possible use the CPU cycles on the recipient side,
conserve
> > CPU cycles in the cloud so that it scales. That's the price you pay for
good
> > current content, but it's an easy price for most to pay because the
cycles
> > on the recipient end usually are being wasted (this is the P2P
proposition).
> >
> > I want other content types to be able to hitch a ride in a RSS channel.
We
> > have a design for this, but it isn't written up yet. The goal is to make
> > exactly the types you mention, audio and video, flow around in higher
> > fidelity, optimizing the user experience and using the Internet when it
> > isn't so busy. It's largely a UI problem, the technology is brain-dead
> > simple. I'll post a note here for sure when it's written up.
> >
> > Basically it flips around the Akamai equation. My goal isn't to get the
bits
> > to you as fast as possible while you wait for them, but to have the bits
> > arrive before you even know they're there. ;->
> >
> > Dave
> >
> >
> > > Interesting...
> > >
> > > How would you distinguish the RSS case from the general problem of
> > > caching and change notification for Web content? Would you propose a
> > > SOAP-based solution to the broader case of wanting to know straight
away
> > > about changes to arbitrary Web-accessible chunks of data (images,
audio,
> > > markup etc). Normally one would try to retrieve all this via HTTP
caches
> > > to avoid hammering the original server; do you reckon it would it make
> > > sense for Web caches to use SOAP or similar to stay more up to date?
> >
> >
> >
> >
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>