[ZOOM] hello and first impressions of the C++ bindings
azaroth at liverpool.ac.uk
Mon Nov 5 14:20:33 CET 2001
On Mon, 5 Nov 2001, Adam Dickmeiss wrote:
> On Mon, Nov 05, 2001 at 12:28:32PM +0000, Robert Sanderson wrote:
> > It returns the current value I thought, ie -after- the set function had
> > run.
> 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).
My thought was that if you return the current value, and for some reason
it -couldn't- set it, then you'd know that the value of the option hadn't
set("databasename", "default") -> (success, returns default)
set("databasename", "this is a name") -> (fail, returns default as it
I guess we wait for Mike to clarify. Either way is easy enough to
implement and use, it just needs to be decided what 'current' means. :)
> > 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
> I think we should aim for three kinds of record accesses:
> 1) render. It's wonderful kick-start for "new" users.
Definitely. MARC is superugly.
> 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.
Right. Providing an abstract data API more complex than getField() is
pretty challenging however.
> > > - 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
Perhaps I misrecall, but wasn't the consensus about Ashley's
SmartConnectionBag (or whatever it was called) that it wasn't something
we wanted to deal with?
It would imply a vastly different OO model I would have thought?
For example, you wouldn't call search on a connection object unless that
connection object is representative of multiple connections. At which
point, interogating it for properties like errorCode, hostname and portnum
becomes meaningless, so it's not a connection object any more?
I'm very possibly wrong here, but that was my recollection. :)
,'/:. Rob Sanderson (azaroth at liverpool.ac.uk)
,'--/::(@)::. 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
More information about the ZOOM