Ben Soares writes:
> In Net::Z3950::SimpleServer, Is there a way to add
xmlns: type
> namespace declarations into the toplevel
zs:searchRetrieveResponse
> tag of an SRU/W searchRetrieveResponse (obviously!)?
>
> This would mean that the declarations only needs to be
put into the
> response once, rather than on every record?
Hi, Ben. Sad to say, there is no mechanism for doing this,
and adding
one would be non-trivial. The actual XML of the SRU
response is put
together by the C code of the YAZ GFS (Generic Frontend
Server) rather
than by SimpleServer itself, so adding the functionality
you're asking
for would involve new releases of both YAZ and SimpleServer.
Worse,
the function that makes the <searchRetrieveResponse>
document,
yaz_srw_codec(), cannot simply be extended to take an
additional
argument specifying a set of namespace declarations to be
added,
because its prototype conforms to the same signature as the
other
codecs used to support other protocols, and it has be
callable
uniformly with the others.
None of this is impossible to change, of course, but it's
not the kind
of thing where half an hour's work will give you what you
need. It
would need to be a small costed project.
> As a side question, I can't get the GHANDLE to retain
values over
> multiple client sessions. I was hoping to store a
global count for
> use in a sessionid, but it never seems to remember the
increment
> even when restored in the GHANDLE. Is this because
I'm using a
> forking server, rather than a threaded one?
Well GHANDLE is not magic -- it doesn't to IPC for you or
anything!
All it's for it to make sure that every time any of the
SimpleServer
callbacks within a process gets called, it's passed a handle
to the
same object. This is useful for things like storing the
result of
parsing a configuration file. If you want all your
SimpleServer
processes to share truly global state, then you have three
choices:
1. Run a single server process which multiplexes its clients
using
select(). You can do this by providing the -S
command-line option,
but see the warnings about this in the YAZ manual.
Running in
threaded mode _might_ also give you what you want -- I've
never
tried it and prefer to avoid thinking about threads.
2. Write some clever IPC code that allows all your forked
SimpleServer
processes to communicate. I can't see how you'd do this
without
introducing a "meta-server" that keeps track of
state, though, in
which you might just as well:
3. Keep the state in a database (whether that's plain file
as you're
doing now, MySQL, or something else).
> We're not using threaded perl in our production
servers. I am
> currently working around this by storing the session
count in a
> file (yuck).
So long as you're locking it properly, that may not be as
yucky as you
think.
> P.S. otherwise, SimpleServer is utterly ace!!
Thanks 
_/|_
____________________________________________________________
_______
/o ) / Mike Taylor <mike indexdata.com> http://www.miketaylor.or
g.uk
)_v__/ "Scientists nearly all the time [...] have the
assumption that
all religion is silly superstition. That all religious
belief
is stuff you've got to cure yourself of, get rid of, if
you're
going to be a good scientist. Noooooooo." -- Robert
Bakker.
_______________________________________________
Net-z3950 mailing list
Net-z3950lists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/n
et-z3950
|