[Yazlist] (no subject)

Quentin Frédérique Robin CHEVILLON quenfred at libertysurf.fr
Sat Jan 3 11:10:15 CET 2004

I had the same problem wanting to build both a Z39.50 client and server.

I had already an important web based application  using PHP and MySQL
and I wanted the database to be accessible by Z 39.50 clients. I didn't
want to translate all my application in Perl. So I created a little
application using the YAZ C API translating Z 39.50 requests into HTTP :
1) a Z 39.50 client sends a query (say @attr 1=1003 KANT)
2) the C YAZ application translates it into HTTP (GET
http://myPhpSite/search.php?crit1=author&val1=KANT HTTP/1.0)
3) the C YAZ application sends the HTTP query to the PHP server.
4) the PHP server treats the query and sends the response in a MARC
format (unimarc)
5) the C YAZ apllication translates the HTTP answer into Z 39.50 and can
send the unimarc notices to the Z 39.50 Client.

The benefits : I don't care about Z 39.50 in my MySQL/PHP application,
and I hadn't to translate my PHP functions into Perl.
The drawbacks : a third application must be running and it only supports
a "light" Z 39.50 (but it is just what I needed)

If someone is intersted, it's very simple and of course totaly free.


-----Message d'origine-----
De : yazlist-bounces at indexdata.dk [mailto:yazlist-bounces at indexdata.dk]
De la part de Sebastian Hammer
Envoyé : vendredi 2 janvier 2004 23:26
À : Discussion on the YAZ Z39.50 toolkit; Discussion on the YAZ Z39.50
Objet : Re: [Yazlist] (no subject)

At 13:24 02-01-2004 -0500, Walter Lewis wrote:

>>This is the combination we mostly choose when we're building the kind
>>service you describe. For my own comfort, I like PHP for building web 
>>applications, but prefer Perl for the kind of data crunching often 
>>involved on the server side.
>Far be it from me to contradict Sebastian <insert picture of me on
>knee with head bowed in humble gratitude> ...
>... but is PHP not essentially a server side environment?  Almost every

>page *I* build with it involves connections to databases, either
>the yaz functions or the wide range of other database connection

Ah. But to a person with a Z39.50-fixation, PHP is a *client*
You use it to build Z39.50 clients with web-based user interfaces. I'm
the PHP people would think of it as a *server* environment, since you
it to make services for users. It's all about your point of view.

>To me the essentially difference is that Perl has DBI and PHP has PEAR 
>(and ASP has ODBC, but we're not going there yet) as database
>layers.  Or does SimpleServer use different layers of magic?

SimpleServer is totally indifferent to what kind of magic you use to
in your database. You could use DBI, you could grep through a textfile,
could use WWW::Search to screenscrape something or SOAP::Lite to access 
Google or Amazon, or Net::Z3950 to build a simple Z39.50 proxy or
much more complicated.

>Some of us, for reasons theoretically related to security, have tried
>reduce the number of tools available on production servers and don't 
>necessarily mix PHP and Perl.  A pure PHP production might be

Yep -- that is our preference *at the moment*. It has benefits and 
drawbacks and there's no-one saying we'll be doing it that way in all 
future. I've no qualms about the security of what we do (I'm not aware
any theorietical security issues specifically related to the mix of Perl

and PHPI), but there are some support and maintenance issues related to 
using multiple languages in the same solution that I'm not happy with. 
However, PHP, AFIK, has typically been associated with webservers and
much else. You can make an SRW or SRU server in PHP since they are
services over HTTP, but Z39.50 needs to live someplace else. I suppose
theoretically possible to rig up a PHP-scriptable Z39.50 servers, but
not sure there'd be much interest in that?

It's not clear to me how you would standardise on PHP alone if you need
build Z39.50 clients *AND* servers, which was the original question, I

Sebastian Hammer, Index Data <http://www.indexdata.dk/>
Ph: +45 3341 0100, Fax: +45 3341 0101

Yazlist mailing list
Yazlist at indexdata.dk

More information about the Yazlist mailing list