ToDo

So much to do, so little time. Any help towards resolving these matters would be much appreciated.

• Build - To Do
• Testing - To Do

Build - To Do

• JNLP descriptors HelpSet
  • Tidy up - complete. X-ref to existing JNLP files.
  • Create a 'search'?
• Resolve content-type. Prefer UTF-8 but HelpSets seem to be in ISO-8859-1.
• Resolve the known exceptions - 1, 2, 3
• Optimize the build.xml file. At last check, it was pushing 55Kb!
  • Track down/remove all redundant JNLP files.
• General refinements to build.xml
  • Add ability to check for existing keystore before generating one.
  • Flip local/live on boolean?
• Turn HelpSetter into a template with configurable package?
• Recheck the pages for missing ACRONYM elements (handy for documenting both acronyms and abbreviations - which flow thick and fast, throughout these pages).
• Make a DesktopHelpSetter as an (JWS based) adjunct to HelpViewer, in the same way HelpSetter is an adjunct for HelpButton. DesktopHelpSetter might register an interest in the .hs file extension as a default handler for 'loose HelpSets'. (N.B. Will require JAC(? or 'all'?) and File objects).

Testing - To Do

A variety of aspects of the deployment still require testing.

• Do the help pages make complete sense? Any sense?
• Try to break the launched HelpSet examples - in ..every way possible.
• Does the Localized help of the IDE Demo appear correctly for locales de, ja?
• To work effectively * for the 'non-integrated/non-embedded' help scenario, the hsviewer.jar or helpsetter.jar need to be explicitly added to the classpath of an application-desc JNLP, in a jar element (e.g. as opposed to being added to the classpath as a component-desc referred to from that same file). This leads to some interesting requirements. AFAIU
  • Only digitally signed resources can be read 'cross-domain'.
  • All archives in a single JNLP must be signed by the same certificate.
  • Which means that any resources such as the HelpSets used for the launch, would themselves need to be factored out into a separate component-desc. (Unless the deployers host an unsigned (or re-signed) copy of the relevant archive on the host domain. **)
• What is the situation on cross-domain * access of loose resources? It has been observed in Java 1.6 that cross-domain access will cause the Plug-In to pop a "Do you want to allow..?" dialog to the end-user, and proceed if they agree. OTOH there is 'word of mouth' evidence that suggests this does not work on Java 1.5 (automatic security exceptions). Is it new? Further testing required.

* To resolve these questions, it would be very handy to have access to a second webstart enabled domain. To host both JNLP files, and small helpsets.

** It might be necessary for deployers to 'hotlink' to archives at the JavaHelp home site, as well as (hot)linking to extensions. This seems preferable to the deployers rehosting the archive, since that might require stripping (or changing) the digital signature, and would also mean the clients miss out on automatic updates to binaries on the JavaHelp site.