- From: Mark Nottingham <mnot@akamai.com>
- Date: Mon, 9 Jul 2001 11:35:38 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: nick@invertica.com, www-ws@w3.org
So this is something I couldn't determine about KN and related solutions, and didn't get into talks deep enough to get a solid answer; Do they do polling from the client, or send asynch messages from the server to the client? If they do polling, it's ugly, and they have built-in latency, as well as infrastructure concerns, but it works. If they do asynch server->client messaging, they fundamentally break the HTTP, and will not work when HTTP proxies, etc. are interposed. Cheers, On Mon, Jul 09, 2001 at 10:40:08AM -0400, Mark Baker wrote: > Hi Nick, > > Nick Nadgauda wrote: > > If I understand their products correctly, what KnowNow, Kenamea, and Bang > > Networks have basically done is build a tunnel over HTTP. They've defined a > > new closed "protocol" -- in this case the protocol being "use 2 HTTP > > connections, one to send and one to receive, and keep the receive one > > constantly open". This works great because they control both ends of the > > connection. Unless other vendors (publishers and subscribers alike) adopt > > this "protocol", you won't have true inter-vendor interoperability the way > > you will with synchronous web services. Kind of like I can't assume that > > everything speaks Tibco or Vitria. > > I don't know much about Bang or Kenemea's technology, but happen to know > a lot about KnowNow's. You're incorrect in your characterization of > them. > > They are definitely not creating a new protocol. There is no tunnelling > going on here. At the server side, it's true that you're accessing URLs > maintained by their software. This is a good and valid thing to do, as > their router provides a stateful service. On the client side though, no > software (runtime or library) is required (though a library may be used, > and a runtime may also be used for persistent routing). It's just GET > and POST, with some *optional* parameters for doing stuff that will > eventually be standardized. > > The basic HTTP idiom that they're following is simple; an HTTP GET on a > router-provided URL implements the subscription, and an HTTP POST to > that node provides for delivery of the event notification. > > MB > -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
Received on Monday, 9 July 2001 14:35:40 UTC