New

diff --git a/archive/architecture-notes b/archive/architecture-notes
new file mode 100644 (file)
index 0000000..4764775
--- /dev/null
+++ b/archive/architecture-notes
@@ -0,0 +1,26 @@
+$Id: architecture-notes,v 1.1 2007-02-20 12:10:02 mike Exp $
+
+The basic approach is this: The IRSpy::Connection is an IRSpy-specific
+subclass of ZOOM::Connection, and its only important extra
+functionality is that it maintains a queue of tasks waiting to be done
+on the connection.  Only one task is active at once: the next queued
+task is executed only when the previous one ends.  (When the queue of
+tasks is exhausted, that markes the end of an IRSpy test, and the next
+test is started, which will in general queue more tasks.)
+
+Tasks are objects of class ZOOM::IRSpy::Task, which has several
+subclasses for the different kinds of task -- Connect, Search,
+Retrieve.  As well as the task-type-specific information such as what
+to search for, each task package also carries a set of ZOOM options
+which are applied immediately before the task is run and them
+immediately reset (so as to make the options as non-modal as
+possible).  In this was, for example, a Fetch package can specify what
+preferredRecordSyntax the operation should use.
+
+So to answer your question: many tasks are queued within the Perl
+object, but only one Z39.50 operation is submitted at a time (per
+connection -- of course IRSpy multiplexes connections, but it keeps
+life as simple as possible for each connection).
+
+Hope this helps.
+