baconbutty.com

Introduction

For a long time I have been using JavaScript + HTML in the browser to create little applications for myself, in a life-hacking vein, such as a note book/outliner, time recording, and Microsoft Word automation.

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:-

• I have learned JavaScript and HTML, and would prefer to stick with that if possible, particularly as I have developed my own extensive library of re-usable functions.
• 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.

Alternatively, developing a .NET or Java application would be more realistic, as C# and Java are easier to learn, and are supported by vast and powerful libraries. However, each again requires me to learn a new mode of creating applications, different to the JavaScript + HTML mode I have become used to.

(In reality I have started to learn .NET and Java, and may eventually go down this path.)

Why not Silverlight, Flash, etc.?

Silverlight

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?

Adobe Air

Adobe Air seems quite an exciting possibility, including as it does, HTML and Javascript; although you need to have the Adobe Air runtime installed.

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

This gives you a fully fledged application, with access to the file system, but in return imposes a number of constraints on the javascript, designed to prevent arbitrary code (other than from the application's own resources) from running after the application has completed loading. E.g. you can only call eval during 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 Sandbox in which you specify which of Air's API will be exposed to your Non-Application Sandbox.

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.

Mozillal XUL

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.

Internet Explorer

Microsoft for years has offered the ActiveX object Scripting.FileSystemObject.

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 Scripting.FileSystemObject.

You simply rename your page to .hta and 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

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 nsIFile and nsILocalFile components, as well as the IE Scripting.FileSystemObject.

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.

See the excellent XUL Planet and the slightly more disappointing and difficult to navigate replacement XPCOM Reference at MozDev.

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

The 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 XMLHttpRequest object.

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.

Conclusion

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 <object> element

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?)