[ZOOM] hello and first impressions of the C++ bindings

Robert Sanderson 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 
changed.

eg:

set("databasename", "default")        -> (success, returns default)
set("databasename", "this is a name") -> (fail, returns default as it 
                                           hasn't changed)

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.

Definitely again. 

> 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

-- 
      ,'/:.          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





More information about the ZOOM mailing list