- From: MegaZone <megazone@livingston.com>
- Date: Mon, 3 Jun 1996 19:47:34 -0700 (PDT)
- 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 UTC