archive/architecture-notes

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