[2078] in java-interest
Re: User machine resident data and code
daemon@ATHENA.MIT.EDU (John Moore)
Fri Sep 22 21:49:22 1995
Date: Fri, 22 Sep 95 16:08:39 -0700
To: java-interest@java.sun.com (Java Interest Mailing List)
From: john@anasazi.com (John Moore)
>John Moore writes:
>> I would like to be able to make an applet/application that is used as
>> follows:
>[...]
>> It is basically
>> behaving as a software agent with local, persistent storage.
>>
>> The issues here are (at least):
>[...]
>> -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.
>[...]
>> 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, [...] 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).
>
>I'm not sure whether you are looking for a Java-specific way to do this, or
>just a protocol. Here's a simple protocol, with at least one problem I can
>see:
Thesee are capabilities that are needed (and some may exist) in the java
runtime environment, such as hotjava. This sort of stuff is quite important
if one is to use java for software agents, which I think is a hot area of
application.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
