Preferences

["Peter B. West" <pb...@powerup.com.au>]

Looking at merging in the HEAD options processing into alt-design, I 
took a look at XML-Commons CLI, which seems to tidy up options 
processing quite nicely.

However, I also took another look at both the Properties and Preferences 
APIs.

It seems to me that the current CLI options processing could be replaced 
by a set of command-line property definitions.  This would be more in 
keeping with the assumptions of Java.  One immediate problem is that any 
line-length restrictions would be sooner violated if we were using 
property definitions.  Not being familiar with the requirements of 
application servers and embedded FOP, I can't comment on the 
implications in that environment.

If we do go that way, however, it brings up the issue of java.util.prefs 
again.  It seems to me that a naive implementation of the API could use 
the existing config and userconfig files to provide the system and user 
persistent stores, at least for reading.  java.util.prefs requires that 
the backing store be writable, however, and I don't know how this would 
fit in a server environment.  (This requirement can probably be 
circumvented at run-time by assuming that the backing store becomes 
unavailable after the initial read: prefs is designed to be robust in 
the face of backing-store unavailability.)

We could address the JVM version issue by wrapping the java.util.prefs 
stuff in org.apache.fop.prefs or ...configuration classes which mimic 
.util.prefs by a thin wrapper around the latter classes, and providing 
for 1.3 compatible versions to be written.  The availability of 1.4 
could easily be tested at run-time, and the appropriate switch set for 
use in org.apache.fop.prefs, reducing the build complexity.

For now, I will just drop org.apache.commons.cli in and use it for 
options processing.  What do folks think about these issues?

Peter
-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: Preferences

["Peter B. West" <pb...@powerup.com.au>]

Peter B. West wrote:
...
> 
> We could address the JVM version issue by wrapping the java.util.prefs 
> stuff in org.apache.fop.prefs or ...configuration classes which mimic 
> .util.prefs by a thin wrapper around the latter classes, and providing 
> for 1.3 compatible versions to be written.  The availability of 1.4 
> could easily be tested at run-time, and the appropriate switch set for 
> use in org.apache.fop.prefs, reducing the build complexity.

Don't mind me... The build complexity will be same as at present, 
requiring 1.3 and 1.4 components to be shifted in at build time.  The 
passing fantasy about a run-time switch afflicts me every now and then.

Peter
-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>