On 1/17/07, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > The last time that I monitored the exchange of a web document retrieved from > java code invoking; > > URL url = ... > InputStream data = url.openStream();
Assuming that's meant to be java.net, right. I didn't know anybody used that anymore though. Any of the 2 HttpClient libs are far superior. > There was no use of persistent connections. An application would have to > perform some very specific actions, as I said to make this work. It doesn't > happen out of the box from a clients perspective as it will with JERI after > the > server is deployed with such a configuration. It happens out of the box for the vast majority of users. Seriously, it's been mainstream since about 1999. > If an application simply opens a socket and transports data, then it is > ultimately responsible for latency, and the ideas and concepts outlined in 817 > are certainly important issues. > > If an application is written using a toolkit or platform or standard which > doesn't provide a level of control that allows the developer/architect to deal > with performance at the appropriate level, then that is where the problem > lies. I'd suggest re-reading the layering section. The tradeoffs there are complex and important. > > > > WS, REST and IIOP, because they lack mobile code > > > > FYI, REST includes a mobile code constraint; > > > > http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 > > <http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_1_7> > > REST can transport mobile code. It doesn't use it. That mobile code doesn't > allow the transport layer or the interface to "change". Sure it does. Have you seen what the WHAT WG is specifying with regards to non-HTTP protocol use? Not that I'd recommend it for most people mind you, but it's available. See; http://www.whatwg.org/specs/web-apps/current-work/#network The caveat is that subsequent interactions with this code will not be RESTful if the usual constraints aren't followed, but REST most certainly provides that hook through mobile code. > 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" 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). It's a feature of REST, by definition. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
