[1516] in java-interest
Re: Third Party Library Loading
daemon@ATHENA.MIT.EDU (Patrick Simpson)
Wed Sep 6 18:38:55 1995
Date: Wed, 6 Sep 1995 12:49:06 -0800
To: hotjava-interest@java.sun.com, java-interest@java.sun.com
From: psimpson@qualcomm.com (Patrick Simpson)
>> From daemon@java.sun.com Tue Sep 5 22:53:51 1995
>> Date: Tue, 5 Sep 1995 19:40:11 -0700
>> From: Michael Lorton <mlorton@eshop.com>
>> To: java-interest@java.sun.com
>> Subject: Re: Third Party Library Loading
>> Comments: Hyperbole mail buttons accepted, v03.19.01.
>> X-Info: To unsubscribe, send 'unsubscribe' to
>>java-interest-request@java.sun.com
>>
>>
>> > Guess I should give an example of what I was thinking about. XYZ Corp
>> > develops the Neato Virtual Reality Card (NVRC), which lets you use a
>> > full featured VR headset. You want to make an app that uses a VR
>> > headset through the NVR Card. Right now you'd have to make native
>> > methods that would interact with the device drvier, and anyone who
>> > wanted to use your applet to do VR stuff would have to download the
>> > native method files and install it on their computer. This is both
>> > inconvienient and poses a security risk, since the native methods can
>> > do anything.
>>
>> Yes, you would need JavaOS (or something close), so that you could
>> write the device-driver in Java.
>
>Acutally, I was thinking more along these lines: the user would already
>have a device driver, so that the native method would only have to
>interact with the device driver. To make it look platform independant,
>a different bundle of files would be fetched from the trusted host
>depending upon what the platform was; the writer of the applet would
>then have to make a reimplement the native methods for each platform
>he wanted the applet usable on.
>-
>Note to Sun employees: this is an EXTERNAL mailing list!
>Info: send 'help' to hotjava-interest-request@java.sun.com
Wouldn't it be just as easy to write ( or have the equipment vendor write )
device drivers in Java with nativce methods and such. Then make these java
device drivers available to users of the equipment, just as normal device
drivers are provided. Then all the app developer needs to do is use the
interface provided by these java device driver classes. This preserves the
intgridy of Java and providing that the source of the java device driver is
reputable then the driver classes are ok too. Remember the problem in
trusting these driver classes is the same as trusting the normal device
driver you are supplied with from the equipment manufatre or third party.
Let me know if this idea is way off base or not. I'm currently trying to
examine this approach in dealing with database interfaces.
Patrick Allen Simpson
Qualcomm Inc
6455 Lusk Blvd.
San Diego, CA 92121-2779
ph: (619) 658 4071
fax: (619) 658 2230
email: psimpson@qualcomm.com
office: Q-205-O
*/* The opinions expressed within are mine and do not necessarily reflect
*/* those of my Employer.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
