By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
460,045 Members | 1,389 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 460,045 IT Pros & Developers. It's quick & easy.

Applets vs JavaScript -- file I/O in public terminals

P: n/a
I'm going to write a client-side web app that deals with local files. This
web app targets mainly public or corporate browser terminals. Normally I
would write an Applet because that's what I know (and because of Java's
extensive library of functions), but I've found that there are many
headaches dealing with Applets in that kind of environment. Not every IT
department installs the Sun JRE and it is usually difficult if not
impossible for the user to do so on that machine if doing so requires admin
priveleges. So I considered switching to JavaScript instead. However I am
wondering how difficult it is to implement file I/O in JavaScript, seeing as
to how the ECMA standard has no such provisions and the tutorials I've seen
on the web indicate that I/O exposure varies from one browser to the next.
If anyone out there has had experience with file I/O in this type of
environment, I'd like to know how much of a headache it is to use
JavaScript.
Aug 25 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a


Kevin C. wrote:
I'm going to write a client-side web app that deals with local files. This
web app targets mainly public or corporate browser terminals. Normally I
would write an Applet because that's what I know (and because of Java's
extensive library of functions), but I've found that there are many
headaches dealing with Applets in that kind of environment. Not every IT
department installs the Sun JRE and it is usually difficult if not
impossible for the user to do so on that machine if doing so requires admin
priveleges. So I considered switching to JavaScript instead. However I am
wondering how difficult it is to implement file I/O in JavaScript, seeing as
to how the ECMA standard has no such provisions and the tutorials I've seen
on the web indicate that I/O exposure varies from one browser to the next.
If anyone out there has had experience with file I/O in this type of
environment, I'd like to know how much of a headache it is to use
JavaScript.


With JavaScript in a HTML documente loaded in a browser it is usually
very difficult to access the local file system of the machine the
browser is running on.

If your HTML document is loaded via HTTP then with normal security
settings there should not be any access to the local file system
possible, unless you do things like signed script.

If your HTML document is loaded from the local file system then there
might be some chances to access the local file system but file I/O is
usually not something the browsers itself expose to script.

So with IE/Win you would rely on using the ActiveX component
FileSystemObject and with normal security settings I think IE will ask
the user to allow to create that object. And with IE on Windows XP SP 2
script and ActiveX is even disabled in the local file zone, the document
is loaded without executing that stuff and the user would need to click
in a warning bar coming up to allow and trigger reloading the page and
execute script.

With Opera you would rely on LiveConnect calls to Java to do file I/O so
you would need the SUN JRE on the client anyway.

With Mozilla you would need XPConnect access which even if your HTML
document with the script is loaded from the local file system requires
your script to ask the user for the privilege and the user to grant that.

Thus if you really need general file I/O on the client then script in a
HTML document loaded in a browser is not the way to go I think, you will
need to install some normal app on the client.

--

Martin Honnen
http://JavaScript.FAQTs.com/
Aug 25 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.