- From: Walden Mathews <waldenm@ilx.com>
- Date: Wed, 19 Jun 2002 14:59:12 -0400
- To: "'Paul Prescod'" <paul@prescod.net>
- Cc: xml-dist-app@w3.org
Paul, > Could you make the logic you are using there a little bit > more explicit? > > Is it something like: > > If asynchronous, best-effort delivery is necessary for web > services then > it is probably also use for "the web" and should therefore be provided > at a level that would make it available to both of them? That makes a > certain amount of sense. Yes, that's good interpretation of my original question, although now I realize I should have said "packet-based" instead of "asynchronous". I can see why streamed responses are important for the Web in many case. Meanwhile, TCP is not particularly "synchronous", is it? > > > ... Is there anything unRESTful > > about asynchronous or connectionless state transfer? > > I don't believe there is anything unrestful about HTTP over UDP. *BUT* > let's say I send you an XML document and it has three > hyperlinks in it. > One is to a stylesheet. One is to some form of semantic > description. One > is to an inclusion (perhaps XInclude). In order for you to process the > document you may need this inclusions. So at that point you need a > request/response MEP. So sending things over UDP is just fine > (especially for performance), So far I'm with you, except I meant not just UDP but an application protocol using it. >but any node that can't > download data from > the Web using HTTP isn't really on the Web and should not expect to > share in the benefits OF the Web. This just seems like defining "Web" in terms of HTTP, or is it saying something deeper? I'll read the abstract before posing any more foolish questions. Thanks. Walden Mathews
Received on Wednesday, 19 June 2002 15:00:15 UTC