- From: Mark Nottingham <mnot@akamai.com>
- Date: Mon, 12 Feb 2001 14:52:17 -0800
- To: Noah_Mendelsohn@lotus.com
- Cc: Martin Gudgin <marting@develop.com>, XML Protocol Comments <xml-dist-app@w3.org>
On Thu, Feb 08, 2001 at 09:48:07AM -0500, Noah_Mendelsohn@lotus.com wrote: > Mark Nottingham writes; > > >> Are you suggesting that there should be a divorce between the nature > >> of the transport binding (in HTTP's case, request/response) and the > >> XP message exchange pattern? > > No, there should be synergy, BUT I am suggesting that the XP level > abstractions (exchange patterns, intermediaries, etc.) should form a > coherent model, and will the level at which most applications are framed. > There is synergy, for example, between SMTP and the underlying binding to > TCP, but most email-enabled applications are coded to SMTP or some > abstraction of it. If it flows well on TCP, so much the better. > > I expect most apps (or the libraries they call) will implement XP at the > level of "Create an envelope for request message, add add body, add header > to mark transacted, add digital signature header, etc." With proper > bindings and implementations of those bindings, this may cause all kinds > of nicely optimized http or even https magic to happen...the same > connection will be used for request and response, etc. Just as in the > email case, the application is working at the higher level. Therefore, > the higher level must stand on its own as a coherent model for use by > applications. Does that make sense? I think so. This is much more ambitious than what I see in the charter, though. I almost want to say that it feels like an API, rather than protocol, issue. Some applications may need this invisibility, but many will not. I dispair of trying to define a taxonomy of all protocol and message path characteristics that XMLP can use; this is a very serious undertaking, and I don't see how leaving it out of scope prevents it being done separately (perhaps in relation to Web Services). -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA)
Received on Monday, 12 February 2001 17:52:51 UTC