[1984] in java-interest
User machine resident data and code
daemon@ATHENA.MIT.EDU (John Moore)
Wed Sep 20 23:11:54 1995
Date: Wed, 20 Sep 95 17:25:03 -0700
To: java-interest@java.sun.com
From: john@anasazi.com (John Moore)
I would like to be able to make an applet/application that is used as follows:
(1) I click on a web page and the applet is downloaded (if this is the first
time), or just those classes that are out of date (if this is a later time)
because the rest are kept on the client. I think this cacheing will be
important because it takes so long to load multiple classes across the
ever-slower internet. Also, my Windows95 Hotjava browser seems to load
classes one at a time, which takes even longer since the TCP set-up time is
usually longer than the download time.
(2) I fire up my Hotjava (or Hotscape or whatever it is) and this new applet
is now on my hot-list or my local home page (by magic... I want this to
happen automagically).
(3) I click on this applet and it gives me a form (another aside: what sort
of forms handling will be available?). I fill it in and the applet surfs the
web a bit for me, based on data from the previous time I ran it. It gets
some stuff, interacts with me, and hangs onto some data for the next time.
It is basically
behaving as a software agent with local, persistent storage.
The issues here are (at least):
-download time for classes
-persistent class caches on clients
-applet inserting itself into the visible world of the browser (obviously this
would have to be tightly controlled)
-storage at the client of applet-specific data that is persistent between
sessions. This is a important from both a security and applications
viewpoint.
-new security issue: a specific applet should be able to:
(a) create it's OWN directory that no other applet can access, but that can
be freely accessed by future instances of this applet.
(b) keep data in that directory that cannot be accessed by any other applet
(c) be authenticatable, and have the ability for classes that it depends
on to be authenticated.
This security issue is critical for my real-world application. I want to be
able to store, for example, credit card information on the local client, and
I certainly don't want some other application - say, a hacked version of the
eating philosophers (GREAT program btw) - to grab that information and pass
it back down the net. At the same time, I don't want the user to have to
answer authentication pop-up boxes every time the applet needs to do things.
We need the concept of an authenticatable application,
with persistent, authenticatable class cacheing, and with local persistent
storage of data that is inextricably tied to the authenticated
application (at
least from within the Java virtual machine).
Other than that, I don't want much :-)
So, Java-wizards, am I smoking the wrong thing? Have you guys been thinking
along these lines?
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
