As part of this, I need to be able to access the local file system to load and save files locally.
I thought I would have a go at sharing my experiences in achieving this through a series of blog entries on the subject.
Why not write a normal application?
My reasons for not writing a normal application are:-
- Our IT system at work will not let me run executables, and does not have Java installed; but it will let me run web pages, and in particular Hypertext Application.
I could of course jump into the deep end and go for a native windows executable using C or C++, but I definitely don't have the time to learn.
(In reality I have started to learn .NET and Java, and may eventually go down this path.)
Why not Silverlight, Flash, etc.?
Silverlight, surprisingly, is not an option at the present, despite its great promise.
This is because Silverlight offers no save functionality in relation to the local file system, other than to a special area set aside for the Silverlight application.
I think Microsoft are looking at this further, but as it stands, Silverlight shuns local file saving; and if it does provide it, it will probably be strictly mediated through dialog boxes.
It also does require me again to learn a sub-set of the .NET Framework; so if I am going for Silverlight, why not .NET?
To be fair, that is no different to needing the JRE installed for Java Appliets.
The thing that puts me off here are some of the security constraints: Air Security.
It is not that they are insoluble, but just a bit irritating.
You have two choices with Air:-
- Application Sandbox
evalduring the initial loading of the application.
This means I have to ensure that my applications do all the important set-up at the load point.
- Non-Application Sandbox
This gives you a normal browser experience, with full
eval, etc; but now you are not allowed to directly access any of Air's file handling API.
You can get round this latter restriction using something called a
Sandbox Bridge, which permits you to create an
Application Sandboxin which you specify which of Air's API will be exposed to your
So it should be possible to do local file handling with the right set-up of Non-Application and Application Sandboxes.
In reality, I am sure that this is quite adequate, but it does require a degree of up-front planning.
The Sandbox Bridge is in fact reminiscent of the signed Java Applet method discussed below.
In a similar fashion, you expose other parts of the full Java API to your web page through the methods you create on the signed applet.
I am not done with Adobe Air by any means, and will be trying it out for size some time.
JavaFX and Java Web Start
I could try developing a Java Web Start application and/or using JavaFX. Like full Java and .NET, it is a question of time, and yet another language.
There is always Mozilla's XUL (pronounced
Zool). This is a possibility, but it is constrained to Firefox.
You must also download the XUL Runner, so it is similar to the Air model.
I believe that XUL is probably a very powerful framework if again I could spend some time on it.
In this series I will howoever be looking at the XPCOM component system the Firefox offers in conjunction with XUL.
What can you do in the browser?
So we are back to the browsers, and what you can do within them.
Microsoft for years has offered the ActiveX object
However, from Internet Explorer 7 ish, it kill-bit'ed the ActiveX object
Scripting.FileSystemObject in the browser. I am not sure if I can bring it back by making the web page trusted.
However, I can run the web page within a
.hta Hypertext Application, which is effectively a web page with elevated permissions, including access to
You simply rename your page to
voila, double-click on it, and your page opens up in a simple window with no security restructions.
This works brilliantly, and is how I currently run my applications. Long may it continue.
I am probably tempting fate with the previous statement, as increasingly, it seems to me, Microsoft are taking the view that there is the web, and there is the client's local file system, and never the twain shall meet, except through a fully fledged windows executable or .NET assembly. For evidence, see the lack of local file save again in Silverlight at the moment; and the protected mode in which Internet Explorer runs in Vista, which prevents signed Java applets from having general load and save capabilities.
Another possibility I have identified is to create a signed ActiveX object using .NET, and to see if I can access it using the
<object> element. I suspect security will be an issue again however.
Firefox has a set of components under its
XPCOM (ActiveX competitor technology) which may do the job (with some idosyncrasies), and in this series I will cover both the XPCOM
nsILocalFile components, as well as the IE
XPCOM components are designed to be part of
XUL but can also be used in a normal web page, subject to presenting the user with a dialogue box requesting permissions.
In addition, Firefox also has Prism which means I could perhaps run it in a similar way to an
.hta Hypertext Application.
Opera / Safari / Google Chrome
As far as I know, none of these browsers offer anything direct in the way of local file handling, natively.
There is the possibility of using Java through
LiveConnect, but I think this has limited security permissions, which are only configuable through a Java Policy file on the client computer; and I think it is being deprecated in favour of the Java plug-in; again, all getting a bit complicated.
However it would seem to be possible to use
signed Java applets, which I discuss a short way below.
XMLHttpRequest object does permit loading of local files in all browsers except for Internet Explorer 7, where you have to use the ActiveX
MSXML2.HttpRequest to get this functionality rather than the native
Signed Java Applets
Signed Java applets are a definite alternative to Scripting.FileSystemObject and XPCOM, and in some ways provide more flexible functionality than either of the other two due to the powerful Java 6 library.
You do have to have the latest JRE installed however.
A signed Java applet is an applet in a
jar file which has been signed using public/private key encription. The necessary utilities for this are included with the JDK.
Signed Java Applets can be given elevated permissions by the browser user, and the user is presented with a dialog box when the applet runs asking for these permissions.
Of course, the exception is Internet Explorer, which, within Vista at least, only has a low security level to start with, and Java Applets running through Internet Explorer get no more rights, unless some special
broker code is applied, which I believe Sun have not yet implemented in the Java plug-in.
I conclusions the local file handling options in the browser are:-
- Internet Explorer : Scripting.FileSystemObject - Hypertext Applications Only
- All Browsers : XMLHttpRequest (MSXML2.HttpRequest in Vista) - Load Only
- Firefox : XPCOM components
- All Browsers : Signed Java Applets (except Vista possibly)
- All Browsers : Perhaps a .NET ActiveX object embedded in an
Not all of the above solutions are cross-operating system though. I think XPCOM and Java are the only cross-operating system options.
In this series I am going to focus on:-
- Scripting.FileSystemObject (IE / Windows only?)
- XPCOM (Firefox / Cross-operating system)
- Signed Java appliets (All browsers / cross-operating system / except Vista?)