[jsword-devel] JNLP and stuff

[Joe Walker]

Mark Goodwin wrote:

>>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
>>
>OK - how about we have ant create a keystore unless there is already one
>there, and have the jar.sign task get values for alias, passwords, etc.
>from properties as I suggested before.   That way, people can build and
>test using their own keystores, and we still have the option of keeping
>keystores generated with genuine certificates safe.
>
Sounds good

>>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.
>>    
>>
>I have to confess I don't like that idea much - as you say it's all or
>nothing (I've tried the IBM tool, and it's OK).  How about we just
>figure out a way of getting ant to sign every jar in
>${target.deploy}/lib ?  That way people don't have to faff with signing
>their own JARs with the keys ant has just generated for them.  I'll look
>at this later today.
>
Yes, point taken

>>>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)
>>    
>>
>That would work.
>
>I've been thinking about the versions loading stuff this morning.  It
>occurs to me that deploying versions in signed JARs with the rest of the
>JNLP distribution is possibly not the best way of getting the Bible data
>to the user across a network / the internet (although I'll continue on
>this tack so we've got something for non-technical testers to work
>with).  
>
>I was thinking it might be good to have a 'version manager' of some
>sort.  This might get the URL of a descriptor which tells it what bible
>versions are available, what driver each version uses, and where the
>data for each version can be obtained.  e.g.
>
><booklist provider="http://www.crosswire.org">
>  <book type="bible">
>    <version name="AV" description="the King James Authorised Version">
>      <variant driver="ser" url="http://foo.com/avser.zip"/>
>    </version>
>    <version name="NIV" description="the New International Version">
>      <variant driver="raw" url="http://bar.com/nivraw.zip"/>
>    </version>
>  </book>
>  <book type="lexicon">
>    <!-- you get the idea-->
>  </book>
></booklist>
>
>The version manager, given this information would be able to present
>both NIV and AV as candidates for installation.  If either were to be
>installed, the manager could download a copy of the selected version
>from the specified URL and give the data to the relevant driver install
>it.
>
>The advantage of this is that it would work for any installation medium
>- You could have a disk with one of these descriptors that tells jsword
>what versions are on the disk, you could then just point the version
>manager at the disk, and the rest would be automatic - no manual faffing
>with versions dirs.
>
>Just a thought.
>
>What do you people think?
>
I think this is a good idea because it solves more than the immediate 
problem. I've got another idea - I'll put it in a separate mail ...

Joe.