Loading ...
Sorry, an error occurred while loading the content.

Re: [syndication] SOAP meets RSS

Expand Messages
  • Mark Nottingham
    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
    Message 1 of 25 , Jan 8, 2001
    • 0 Attachment
      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@...>
      > 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@...
      > > (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/
    Your message has been successfully submitted and would be delivered to recipients shortly.