From e6eb9c2d889da43a237e582176c4a082a9ad2da7 Mon Sep 17 00:00:00 2001 From: Martin Mares Date: Thu, 19 Sep 2002 18:26:37 +0000 Subject: [PATCH] Robert> uff, na prvni pohled nic nechapu, asi je to moc chytre :) So I decided to learn how to use POD and write a POD documentation for the module (in usual Perl fashion, it's a part of the module). Use perldoc or pod2${format} to view or convert it. --- lib/perl/Query.pm | 81 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/lib/perl/Query.pm b/lib/perl/Query.pm index bb4c9c1d..2822a0ab 100644 --- a/lib/perl/Query.pm +++ b/lib/perl/Query.pm @@ -5,6 +5,87 @@ # This software may be freely distributed and used according to the terms # of the GNU Lesser General Public License. +=head1 NAME + +Sherlock::Query -- Communication with Sherlock Search Servers + +=head1 DESCRIPTION + +This perl library offers a simple interface for connecting to Sherlock +search servers, sending queries or control commands and parsing the +results. + +First of all, you have to use + + my $conn = new Sherlock::Query('server:port'); + +to create a new connection object (unconnected yet). Then you can call + + my $res = $conn->command('command'); + +to establish the connection, send a given command to the search server +and gather the results (see below) or, if you want to send a normal query, + + my $res = $conn->query('"simple" OR "query"'); + +which does the same as C<< $conn->command(...) >>, but it also parses the +results to a representation convenient for handling in Perl programs +(again, see below). + +Currently, you can use a single connection to send only a single command or query. + +=head1 RESULTS + +The I of the search server (i.e., the lines it has returned) is always +available as C<< $conn->{RAW} >> as a list of strings, each representing a single +line. + +Parsed results of queries are stored in a more complicated way, but before +explaining it, let's mention a couple of axioms: Any search server I +(header, footer, a single document of answer) is always stored as a hash keyed +by attribute names. Ordinary single-valued attributes are stored as strings, +multi-valued attributes as (references to) arrays of strings. When an object +contains sub-objects, they are stored as references to other hashes, possibly +encapsulated within a list if there can be multiple such objects. Most objects +have an extra attribute C containing the original description of the +object, a sub-list of C<< $conn->{RAW} >>. + +The parsed answer consists of three parts (please follow F to +get a better picture of what does the server answer): header C<< $conn->{HEADER} >> +(an object, as described above), footer C<< $conn->{FOOTER} >> (object) and document +cards C<< $conn->{CARDS} >> (a list of objects). + +The I
contains all the standard header attributes and also C<< $hdr->{D} >> +which is a list of sub-objects, each corresponding to a single database and +containing per-database attributes like C (word list). + +The I