- From: Patrick McManus <mcmanus@nysernet.org>
- Date: Mon, 3 Jun 1996 09:46:49 -0400 (EDT)
- To: megazone@livingston.com (MegaZone)
- Cc: www-html@w3.org, www-talk@w3.org
In a previous episode...MegaZone said: -> -> I talked to some of the Sun reps and presented the idea of getting a well -> known port for Java servers, like we have httpd on port 80, telnet on 23, You're mixing two concepts. http and telnet are protocols, that is why they have well known ports. Java classes are content.. how can you assign a TCP port to content? The question is how to transfer java.. typically right now you use http or ftp. Are you suggesting they are inadequate? -> environment. The majority of the designs anticipated using Java are more -> properly handled when viewing Java as a new resource type instead of linked -> hard with http/html. Huh? HTTP can transfer any entity.. it is designed to be a general object transfer mechanism. text/html is no more intrinsic to it than application/x-excel, image/gif, application/x-imadethisupinyear2002 or application/java. In addition http 1.1 will support end to end authentiaction of objects, pipelines, and partial range requests for resumption of interrupted transfers. Not to mention transparent content-negotiation of resources so someone could specify they prefer C code to Java code for the same resource and get it if both are available. Why on earth would we throw all that out to invent yet another transport protocol? -> Most critically the concept of clients sending applets -> *to* a server to be executed on the server - this is outside the scope of an -> httpd. Read the spec http://www.w3.org/hypertext/WWW/Protocols/Overview.html. With PUT and POST, http is very bi-directional. -> This would keep the higher load of handling applets off of the httpd. This proposal doesn't magically invent CPU cycles or hardware. I can forsee the situation of a multi-threaded http server serving 50 documents a minute, and 50 java classes a minute. Under a new dedicated java server the http server is now only doing half as much work but has less than half of the CPU available to it because the java server is taking just as much CPU as it is, plus the burden on the OS has increased to manage the extra proceeses. This is a performance loss, not to even mention the potential derogatory impacts to the efficiency of any LRU caches the http server may be maintaining. For the folks that mentioned ORBs.. there are already a couple of implementations of note: Black Widow's announcement can be found here: http://www.pomoco.com/bwdprs.html -P
Received on Monday, 3 June 1996 09:50:01 UTC