[jsword-devel] JNLP and stuff

[Joe Walker]

Hi,

Mark Goodwin wrote:

>I spent a bit of time last night working on the JNLP / Webstart stuff.
>I've not committed stuff because I've not finished, and there's some
>things I want to run by people first.
>
>1) I'm not going to add the keystore to cvs (if we do ever get a proper
>certificate, it would be silly to make the keystore and the associated
>password / alias info publicly available for obvious reasons, so why
>start now?) - this means I'll be putting all the keystore path / alias /
>passwd info as properties, and making the jar.sign target do nothing if
>these aren't set.
>
I think the principles are: 1. everyone ought to be able to build and 
test, 2. Much as I think forks are a bad idea, if a fork happens then 
they should have their own name and own keystore and so it is legitimate 
to keep tight reign on the real keystore.
We could have some ant tasks that created a keystore from scratch for 
testing and debug - I think I sused it out once before, I'm sure I can 
find it again.

>2) What do we do about 'other' jars (i.e. no jsword.jar).  These are not
>currently signed by the ant build, but probably should be - there's
>really no reason to put signed jars in CVS - they're useless to people
>without the keystore anyway.
>
I wonder if we should unroll all needed jars, and re-roll them into 
jsword.jar. It would make things simple, and could make it easy for us 
to use a jar compacting tool. IIRC IBM have a fancy thing that examines 
a jar file and rips out all of the unused classes and even methods! Not 
sure if this works well though.
OTOH it would make upgrade downloads bigger because it's an all or nothing.

>3) The NetUtil.getURLAsFile(URL) method can't use a
>Resouce.getTempworkingDir() style method - Resource belongs to jsword
>package, NetUtil is in common.  At present I've implemented getURLAsFile
>using File.CreateTempFile so it uses the system temp folder -  this
>willl do for the time being, but perhaps we should provide a project
>agnostic interface under $blah.jsword.common for obtaining commonly
>neaded things (like tempWorkingDirs, property files) which is
>implemented by $blah.jsword.Resource?  Just a thought.
>  
>
Um, yes. I guess I'd add: NetUtil.[g|s]etURLCacheDir(File) and have 
config set this before we make any calls to getURLAsFile(URL)

>I think that's about it...
>
>I'll hack away at the ser bible stuff until I've got something that
>works (prob tonight - busy during the day).  I'm not clear on some of
>the design details yet, so I'll put it on a branch for Joe (or others)
>to check over before I merge to the trunk.
>  
>
Shout if you need any more docos on ser. There is javadoc, but it may 
well be out of date. The principle is very simple - Ser was designed for 
speed and speed alone, there are 2 basic questions asked of SerBible, 
getText(ref), and search(word). All possible answers are serialized 
(hence the name) and so everything is quite simple.

Side issue: As soon as Sword support is finished we will need to suss 
out how we could add this in. In SwordBibleDriver there is (unless Keith 
has taken it out) a setSwordDir option to mark where Sword is installed 
to get Sword modules. I'd considered altering this to a path rather than 
a single directory, (this might be needed if JSword is going to allow 
module installation, but not risk killing a working Sword installation, 
and use existing Sword modules at the same time.)
So could a path include a URL?!

Joe.