[ZOOM] pointers (fwd)

Adam Dickmeiss adam at indexdata.dk
Thu Nov 1 20:51:38 CET 2001


On Thu, Nov 01, 2001 at 04:26:20PM +0000, Robert Sanderson wrote:
> 
> Froth.  Too many tasks at once. Will eventually remember not to just hit
> reply.
> 
> > > As we all know, there's several implementations out there that don't
> > > support named resultsets.  This means that the default resultset will be
> > > reused for each search.
> >
> > But this is equally a problem whether you generate a new resultSet
> > object with "conn->search()" or "new resultSet".  In all cases, you
> > always have to be alive to the possibility that the server will
> > suddenly decide not to bother supporting any or all of your result
> > sets.  (This is true even if you only have one RS!)
> 
> I would think that a new resultSet implies that you will always create a
> new object, whereas conn->search() could return an existing result set
> object after it has been modified to the actual status of the resultset on
> the server that it represents.

If conn->search returns a potential existing object, then it follows that
the connection owns the result set completely. From that it follows that the
user of the API can no longer refer to the result set when doing a second
search, since that result set may no longer be valid (not even the pointer).
If we were going along that route, then I'd rather drop the result sets
completely. That's what I did for the PHP/YAZ which only uses unnamed
result sets which has one object: connection.

It would certainly be a shame to go in that direction for ZOOM (the
acronym must be changed, then). Let's keep control of the result sets on
the client side and let's make it possible for us to keep them alive
as long as we wish and destroy them when we like.

I have to admit that the implementation of a ZOOM driver that supports
result sets that aren't PUBLICLY owned by connections is not that
easy. In the ZOOM implementation of YAZ (C only) each connection keeps
track of all "live" result sets. And each result set has a pointer
to a "parent" connection object, so that when doing present requests,
for example, it can use the connection driver to do protocol stuff,
etc. Because the connection has track of result sets we can do
researching easily for targets doing unnamed result sets only.

[snip]
 
> 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
> 
> 
> _______________________________________________
> ZOOM mailing list
> ZOOM at indexdata.dk
> http://www.indexdata.dk/mailman/listinfo/zoom

-- 
Adam Dickmeiss  mailto:adam at indexdata.dk  http://www.indexdata.dk
Index Data      T: +45 33410100           Mob.: 212 212 66



More information about the ZOOM mailing list