Re: [syndication] SOAP meets RSS

[Mark Nottingham <mnot@mnot.net>]

The application is different, but I think the problem is the same -
there's a need for a way to describe a channel that pushes out
messages that describe, in some way, changes to / metadata about
resources contained in the channel.

I believe that a well-designed solution can encompass both
applications, and that it's beneficial to do so, because of the
difficulty in making such a protocol scale well across the Internet.


On Sun, Jan 07, 2001 at 10:21:01PM -0800, Dave Winer wrote:
> 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/
> >
> >
> >
> 
> 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/