[ZOOM] Some 1.4 options questions
ajk at mds.rmit.edu.au
Thu Feb 5 01:02:38 CET 2004
On Wed, Feb 04, 2004 at 10:41:27AM +0000, Mike Taylor wrote:
> > So host is, admitted, is a terrible name. What would be better a
> > name?
If things go this way (that is, have a single server string allowing
it to be somewhat opaque to the API), it would be good to standardise
the strings forms. Eg: precisely how to specify a
(1) Z39.50 connection "z3950:" host [ ":" port ] ?
(2) SRW connection "srw:" host [ ":" port ] "/" database ?
(3) SRU connection "sru:" host [ ":" port ] "/" database ?
The above are just examples. Adam posted what he accepted recently,
but I dont think it was precise in terms of the grammar of where to
put slashes and colons etc. May as well use the grammar already
supported by someone (eg: YAZ).
> > In the easy mode, start, count and presentChunk is first record to
> > fetch, number of records to fetch and number of records to fetch in
> > each present request respectively. The special presentChunk value 0,
> > means present all records in one go (count records).
> What effect does "count" have, then?
My reading is 'start' & 'count' are for piggyback search requests, and
'presentChunk' is for present requests. If this was the case, would you
still have the 'piggyback' option? If 'count' is zero, then there is
no piggyback in effect.
> > It is a little confusing, though. The notion of "default" settings
> > or settings getting propagated to child instances ...
> Sorry, I would have been open to do this differently when we were just
> starting out with ZOOM, but I don't want to change everything now...
I agree. Appologies for bringing the topic up again.
By the way, I am pottering along again on my ZOOM implementation.
I am starting from the abstract spec however, not the current Java
bindings. I am also doing things 'the Java way', based on the
abstract spec. For example, Java has the concept of JavaBeans,
where properties have explicit set/get methods. The exact prototypes
are defined by the JavaBeans spec (eg: the set method must return void,
not the old value). Having explicit methods (rather than a get option
method that takes the name of the option as a string), one named
per option, works well in the IDEs - they pop up a list of supported
method names so you don't have to guess what options are available.
Avoids spelling errors in strings too.
So I am feeling a bit torn between keeping things as close as possible
to the ZOOM specs as is, versus making the API as much like other Java
APIs as possible (according to my somewhat limited Java experience).
I am leaning towards being Java friendly at the moment - maybe I
will call the API ZOOM-ish rather than ZOOM conformant ;-)
If anyone is interested, I can put up beta Javadoc of the API in the
near future for comment - knowing that it is not strictly ZOOM.
ps: I am hoping to release a low level packet Z39.50 encode/decode stuff
for Java soon too. My ZOOM-ish layer is built on top of this library.
Alan Kent (mailto:Alan.Kent at teratext.com.au, http://www.mds.rmit.edu.au/~ajk/)
Project: TeraText Technical Director (http://teratext.com.au) InQuirion Pty Ltd
Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia.
Phone: +61 3 9925 4114 Reception: +61 3 9925 4099 Fax: +61 3 9925 4098
More information about the ZOOM