Problems encountered in creating JScoreML
- JScoreML is an applet - meaning it is a running application deployed via the web onto your computer with the stipulation that it may never access any local files on the client computer. This posed a whole slew of problems in allowing JScoreML to save the score as a MIDI file on the client computer and in the implementation of the screen reader functionality.
Solution: The most ideal solution would be to make JScoreML a signed applet. This signature would verify that the applet did indeed come from the Adaptive Technology Resource Centre (ATRC) at the University of Toronto and query the user as to if they will allow this applet access to files on their local file system. This would allow the user to save the score as a MIDI file on to his/her local file system and (this is speculation) allow the screen reader functionality to work. The only drawback to this solution is that signing an applet requires attaining a digital signature from an RSA Certificate Authority (such as Verisign) which cost around $400 U.S. and are valid for one year.
Another partial solution (and the one implemented) is for the user to pass a parameter into their Java Plug-in specifying a security policy giving all applets unrestricted access to the client's local file system. Then the user would download the JScoreML applet, interact with the application, and then delete the security policy parameter from their Java Plug-in so as to not allow any potentially dangerous applets unrestricted acces to their local file system. This solution allows the user to save the created score as a MIDI file on their local disk - but produces a NullPointerException when trying to initialize the local system's screen reader software. The screen reader functionality has been tested running JScoreML as a local application and does in fact work, but is unavailable in the current release of JScoreML due to this screen reader initialization error encountered.
- JScoreML requires additional Java API packages and musical fonts. Because of the demanded functionality of a musical notation application and that this application is run via the web, many additional Java packages and two musical fonts and required to run JScoreML (see Requirements to run JScoreML ). This takes away from the expected simplicity of interacting with information on the web - one of the driving forces behind making this application an applet.
Solution: Java Web Start? - Java Web Start would launch a JScoreML application at a simple click of a link, but the problem of the additional API packages would only be solved if we would become a Java vendor and have all the required API packages installed in our version of Java. But this opens a huge licensing can of worms we would not want to get into. Also a Java Web Start application of this nature would require our JAR files to be signed with a signature obtained from an RSA Certificate Authority (see problem 1 above).
- Only the JAXP 1.0.1 XML parsing API can be used - Because JScoreML is an applet, it has added restrictions on what files can be accessed on the client's file system. Other XML parsing API's, such as the Apache Xerces parser, make a system call in the initialization of a DOM. This causes a security exception in the JScoreML applet and hence, no XML processing can be accomplished. The JAXP 1.0.1 XML parsing API does not make this system call and hence, allows JScoreML to initialize a DOM. More research into this topic will come.
Go back to main JScoreML