W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1996

Re: Java and HTML and well known socket numbers

From: MegaZone <megazone@livingston.com>
Date: Mon, 3 Jun 1996 19:47:34 -0700 (PDT)
Message-Id: <199606040247.TAA08302@server.livingston.com>
To: holtrf@destinyusa.com (Russell Holt)
Cc: megazone@livingston.com, www-html@w3.org, www-talk@w3.org
Once upon a time Russell Holt shaped the electrons to say...
>What does it mean to be "optimized to serve Java applets"?
>I can see an advantage in having a lean server which does nothing but
>serve GET requests for java applets. It skips all the extra baggage

I was thinking in terms of a lean server that handles Java and doesn't deal
with the other types of content.  Expecially in an environment where Java
Terms are in heavy use (IBM is considering replacing 3270s with Java Terms
for example, amongst many other such concepts).  Also the server could be
written with a much tighter, less-flexible security model to make for
the fewest number of possible leaks.  This is rather important when you
start accepting PUTs on applets to run on the server.

>(in this case) that an httpd would have to go through, when we'd already
>know the answers to most of its questions.

Yes.

>But are you thinking about some other type of negotiation that
>might go on, which http servers don't or can't do? even server APIs?

I don't believe HTTP, even 1.1, will do everything it will be called
upon to do if the Java explosion really takes off.  People are creating new
uses daily.  But that probably just means an evolotion of HTTP - UNLESS 
someone comes up with some keen new use of Java that requires some new
pardigm in server side operation - perhaps that is just needless to a
'normal' HTTP, or even obstructive - but that is great for Java.

>future needs - such as? applet verification? encryption?

Securely transacting Java applets from and *to* servers and executing the
applets on the server in a fully secured and sanitized environment.  From
what I've seen of HTTP 1.1 I'm not satisfied as an admin that it will do
the job, not are the other admins I've talked to.  Most of them feel the
concept is very keen, but the implementation scares the hell out of them
for its security implementations.  And with client-server interactive Java,
I could see advantages in a 'stated' connection instead of pseudo-state
with cookies as it is now.  Everytime the client talks to the server we get
at least 3 packets of setup and 2 of teardown since servers don't hold 
connections open for an extended two-way interaction (aside from content
negotiation).

And just having a different port number would make most admins I've talked
to happy since they could do better firewalling and security work if Java
was not tied directly to port 80, which is synonymous with WWW.  Sure,
technically it is just the HTTPd port - but de facto that means WWW.

>Question- is it possible for a java applet to begin execution during
>download? That's a browser issue though.

Well, maybe, but I think it would be tricky to start running a binary
before the rest is there.

-MZ
--
Although I work for Livingston Enterprises Technical Support, I alone am
responsible for everything contained herein.  So don't waste my managers'
time bitching to them if you don't like something I've said.  Flame me.
Phone: 800-458-9966  support@livingston.com  <http://www.livingston.com/> 
FAX: 510-426-8951    6920 Koll Center Parkway #220, Pleasanton, CA 94566
Received on Monday, 3 June 1996 22:48:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:19 GMT