From 498d80015f34aba7e644f67a5da94236b63ed7b3 Mon Sep 17 00:00:00 2001 From: Mike Taylor Date: Tue, 20 Feb 2007 12:10:02 +0000 Subject: [PATCH] New --- archive/architecture-notes | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 archive/architecture-notes diff --git a/archive/architecture-notes b/archive/architecture-notes new file mode 100644 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. + -- 1.7.10.4