On 17.01.2007, at 23:08, Gregg Wonderly wrote: > Mark Baker wrote: >> On 1/17/07, Gregg Wonderly <[EMAIL PROTECTED] <mailto:gergg% >> 40cox.net>> wrote: >>> I think it should be fairly obvious that "slow" on a network is >>> almost always >>> related to "latency" of transfer/transport between systems. There >>> are a couple >>> of issues to consider, for me. One is connection setup time for a >>> transfer/transport operation. Many HTTP based systems will >>> experience this >>> latency on every remote operation unless some very specific >>> features of HTTP are >>> configured/available. >> >> That's no longer the case; persistent connections are pervasively >> supported and used and have been for many years. > > The last time that I monitored the exchange of a web document > retrieved from > java code invoking; > > URL url = ... > InputStream data = url.openStream(); > > There was no use of persistent connections. An application would > have to > perform some very specific actions, as I said to make this work.
You shouldn't blame the architectural style for a bad implementation of the HTTP connector. > > REST can transport mobile code. It doesn't use it. That mobile > code doesn't > allow the transport layer or the interface to "change". Why would you want to change the transport layer? And sure, the interface in a REST conforming system cannot change (must not change). But mobile code affects an applications hypermedia engine, so the effect is conceptually the same. > One might use REST/HTTP > to load a webpage with an applet or javascript which uses NO HTTP > to talk to the > server. But, I don't consider that a "feature of REST" No, of course not....it would be against REST principles to have conversations that don't use the uniform interface (HTTP in this case). Jan > as much as a "feature of > Java" or a "feature of javascript" (the feature is the ability to vary > transport/transfer techonology based on need). > > Gregg Wonderly > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] >
