proxy'ing z39.50 - comments and questions

 I am getting close to having this done, which has been mentioned on this 
list in the past. Before I do this mail, last time this was touched on
it came up there are two approaches to proxying:
  1. a generic proxy like unto http proxies
  2. a central service proxy that is used for some degree of
	centralized control.

I do the second because of things like requiring control of contracts (and
thus passwords and where a service comes from) and a desire that from
my users perspective all the services are provided by the "library". That
is, we don't want users to care if a DB is locally mounted or purchased
under contract and linked to externally.


  That said - I thought I was getting close and then I hit the issue of
how much I have to rewrite the PDUs.  So my question is - has anyone done
this? Would love to hear what others thought had to be done.

  My first pains with this:
     - userid/passwords added to init. Possibly concerns over the PDU/record
       size parameters.
  search though is my real concern:
     - will change database name (the vendor certainly calls it different)
     - but then I realized what about the RPNquery?
	- my clients allow, and my users reference earlier sets. I see lots of
	       set5 and (information(w)retrieval)
	  but "set5" in my proxy <-> client might have a different name
	  in  proxy <-> z39.50DBserver.  Esp if someday I have multiple
	  users/clients using the same database link.
	- how about attributes. My users/clients use "default" alot. But
	  what "default" means in my DB setup/server is alot different
	  in some other servers (especially [naming names] NLMs).  My setup
	  sort of handles this, but requires changing "default" to
	  USE "title or abstract"

 
 And I am worried that I have stepped into a real mess, of which the
above is just the tip.  So am asking - has anyone dealt with these issues
at all??

  THanks,   Bob Waldstein  wald@lucent.com

Received on Thursday, 21 September 2000 09:19:40 UTC