Re: Java and HTML and well known socket numbers

Patrick McManus (mcmanus@nysernet.org)
Mon, 3 Jun 1996 09:46:49 -0400 (EDT)


From: Patrick McManus <mcmanus@nysernet.org>
Message-Id: <199606031346.JAA25917@pat.nyser.net>
Subject: Re: Java and HTML and well known socket numbers
To: megazone@livingston.com (MegaZone)
Date: Mon, 3 Jun 1996 09:46:49 -0400 (EDT)
Cc: www-html@w3.org, www-talk@w3.org
In-Reply-To: <199606010502.WAA12419@server.livingston.com> from "MegaZone" at May 31, 96 10:02:36 pm

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