archive/architecture-notes

   1 $Id: architecture-notes,v 1.1 2007-02-20 12:10:02 mike Exp $
   2
   3 The basic approach is this: The IRSpy::Connection is an IRSpy-specific
   4 subclass of ZOOM::Connection, and its only important extra
   5 functionality is that it maintains a queue of tasks waiting to be done
   6 on the connection.  Only one task is active at once: the next queued
   7 task is executed only when the previous one ends.  (When the queue of
   8 tasks is exhausted, that markes the end of an IRSpy test, and the next
   9 test is started, which will in general queue more tasks.)
  10
  11 Tasks are objects of class ZOOM::IRSpy::Task, which has several
  12 subclasses for the different kinds of task -- Connect, Search,
  13 Retrieve.  As well as the task-type-specific information such as what
  14 to search for, each task package also carries a set of ZOOM options
  15 which are applied immediately before the task is run and them
  16 immediately reset (so as to make the options as non-modal as
  17 possible).  In this was, for example, a Fetch package can specify what
  18 preferredRecordSyntax the operation should use.
  19
  20 So to answer your question: many tasks are queued within the Perl
  21 object, but only one Z39.50 operation is submitted at a time (per
  22 connection -- of course IRSpy multiplexes connections, but it keeps
  23 life as simple as possible for each connection).
  24
  25 Hope this helps.
  26