[ZOOM] hello and first impressions of the C++ bindings
adam at indexdata.dk
Mon Nov 5 13:51:42 CET 2001
On Mon, Nov 05, 2001 at 12:28:32PM +0000, Robert Sanderson wrote:
> > - why is the set option call retyrning the old value?
> > i wood argue that close to all clients setting a option is
> > not interested in the old value. and if it ware the call of
> > the get function is not be a large overhead.
> It returns the current value I thought, ie -after- the set function had
It was my impression that it does return the old value. Note that if you
pass a new value, then you know that already. If you don't pass a value
then it returns the old value (which is the current value, anyway).
I guess, Mike was thinking in terms of the signal(2) unix call. When
a parameter passing works like that, you're able to provide a push/pop
> set("databasename") -> undefined??
> set("databasename", "default") -> "default"
> set("databasename", "new") -> "new"
> set("databasename") -> "new"
So my interpretation is that your example should go like this:
set("databasename") -> undefined?
set("databasename", "default") -> undefined?
set("databasename", "new") -> "default"
set("databasename") -> "new"
> > always miss one importend item. why not just give the client programmer
> > the OID and defines the names of the regristrated OIDS from the motherpage.
> > then the programmer dont need to know that 1.2.840.10003.5.14 is danMarc
> > unless he wants to. and the use of a oid class.
> I don't think we need an OID class. As far as I can see, it would simply
> be an object with two properties - OID and Name.
> As there is a defined set of OIDs, it makes sense to me at least that they
> should be simply defined in what ever mechanism is convenient for the
> language to map between two strings.
> I think that the Get Field function is useful, but will be the point at
> which most implementations stop with only MARC. Of course, there can be
> competition amongst ZOOM implementations (which is healthy) such that if
> the C++ binding comes with libxml, libmarc, libgrs1, libsutrs and
> libsomethingelse, then it's likely to be taken up more than the TCL
> implementation which only handles marc and grs1.
I think we should aim for three kinds of record accesses:
1) render. It's wonderful kick-start for "new" users.
2) raw. Obviously needed if you want complete control (or extend your
ZOOM implementation). To do something useful, you need to have the
OID for the record as well as the raw bytes.
3) structured/DOM - like retrieval mechanism. For easy conversion to
hash/array structures to higher-level languages. All MARC/XML/GRS
records can be converted to this one easily. For SUTRS/HTML this
one doesn't do you good.
> > - personaly i think the ZOOM api shut returns records as octetsreams, and
> > let the client application decode the record. optionaly supply a support
> > lib for GRS-1.
> There is a get raw record function.
> I recall a conversation on the ZIG bus about what is returned for GRS1
> in this, but not the outcome. I -think- it was an implementation specific
> rendition of the GRS1. (I hope so at least, because that's why my
> implementation will need to return to TCL)
> > - Howto is one access multible database on the same target. i am missing
> > a list of databases as part of the search class.
> I think that's beyond scope, in the same way that multiple targets is.
Multiple databases is not beyond the scope of ZOOM. It's so easy to
implement and offer. Multi-target should be adressed too. It doesn't
have to be *that* easy, but it has to be there. Otherwise ZOOM is
useless for real-life applications. The ZOOM C binding part of the
YAZ 1.8.X offers both, BTW.
> ,'/:. Rob Sanderson (azaroth at liverpool.ac.uk)
> ,'-/::::. http://www.o-r-g.org/~azaroth/
> ,'--/::(@)::. Special Collections and Archives, extension 3142
> ,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
> ____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
> I L L U M I N A T I
> ZOOM mailing list
> ZOOM at indexdata.dk
More information about the ZOOM