ACE_Stream based pipeline implementation in the works. This provides

interfaces for Sumedh to use.

5 files changed, 82 insertions, 332 deletions

diff --git a/apps/JAWS/server/JAWS_Pipeline.cpp b/apps/JAWS/server/JAWS_Pipeline.cpp
new file mode 100644
index 00000000000..c2f53b403d8
--- /dev/null
+++ b/apps/JAWS/server/JAWS_Pipeline.cpp
@@ -0,0 +1,35 @@
+// $Id$
+
+#include "JAWS_Pipeline.h"
+
+JAWS_Pipeline::JAWS_Pipeline (void)
+{
+}
+
+int
+JAWS_Pipeline::open (void * = 0)
+{
+  // Simply call into the virtual svc() method.
+  if (this->svc() == -1)
+    ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "JAWS_Pipeline::svc"), -1);
+  return 0;
+}
+
+int
+JAWS_Pipeline::close (u_long = 0)
+{
+  return 0;
+}
+
+template <class TYPE>
+JAWS_Pipeline_Handler<TYPE>::JAWS_Pipeline_Handler (void)
+{
+}
+
+template <class TYPE> int
+JAWS_Pipeline_Handler<TYPE>::put (ACE_Message_Block *mb, ACE_Time_Value *tv)
+{
+  TYPE *data = (TYPE *) mb->data_block ();
+  status = this->handle_input (data, tv);
+  return (status != -1) ? this->put_next (mb, tv) : -1;
+}
diff --git a/apps/JAWS/server/JAWS_Pipeline.h b/apps/JAWS/server/JAWS_Pipeline.h
new file mode 100644
index 00000000000..b2462caa422
--- /dev/null
+++ b/apps/JAWS/server/JAWS_Pipeline.h
@@ -0,0 +1,46 @@
+/* -*- c++ -*- */
+// $Id$
+
+#if !defined (JAWS_PIPELINE_H)
+#define JAWS_PIPELINE_H
+
+#include "ace/Synch.h"
+#include "ace/Service_Config.h"
+#include "ace/Stream.h"
+#include "ace/Module.h"
+#include "ace/Task.h"
+
+typedef ACE_Stream<ACE_NULL_SYNCH> JAWS_Pipeline_Stream;
+typedef ACE_Module<ACE_NULL_SYNCH> JAWS_Pipeline_Module;
+typedef ACE_Task<ACE_NULL_SYNCH> JAWS_Pipeline_Task;
+
+class JAWS_Pipeline : public JAWS_Pipeline_Task
+  // = TITLE
+  //   Methods that are common to pipeline components
+{
+public:
+  JAWS_Pipeline (void);
+  // ACE_Task hooks
+
+  virtual int open (void * = 0);
+  virtual int close (u_long = 0);
+};
+
+template <class TYPE>
+class JAWS_Pipeline_Handler : public JAWS_Pipeline_Task
+  // = TITLE
+  //   Methods that are common to pipeline components
+{
+public:
+  JAWS_Pipeline_Handler (void)
+  // ACE_Task hooks
+
+  virtual int put (ACE_Message_Block *mb, ACE_Time_Value *tv = 0);
+  // inherited from ACE_Task
+
+  virtual int handle_input (TYPE *data, ACE_Time_Value *tv) = 0;
+  // Callback hook for specialized data processing
+};
+
+
+#endif /* !defined (JAWS_PIPELINE_H) */
diff --git a/apps/JAWS/server/Makefile b/apps/JAWS/server/Makefile
index 5aebd6d154a..7904248b01a 100644
--- a/apps/JAWS/server/Makefile
+++ b/apps/JAWS/server/Makefile
@@ -17,7 +17,7 @@ MYFILES  	= \
 	HTTP_Config \
 	HTTP_Handler \
 	HTTP_Helpers \
-	Pipeline \
+	JAWS_Pipeline \
 	HTTP_Request \
 	HTTP_Response \
 	Parse_Headers \
diff --git a/apps/JAWS/server/Pipeline.cpp b/apps/JAWS/server/Pipeline.cpp
deleted file mode 100644
index f1c221262ac..00000000000
--- a/apps/JAWS/server/Pipeline.cpp
+++ /dev/null
@@ -1,133 +0,0 @@
-// $Id$
-
-#include "Pipeline.h"
-
-JAWS_Protocol_Pipeline::JAWS_Protocol_Pipeline (void)
-{
-}
-
-JAWS_Protocol_Pipeline::JAWS_Protocol_Pipeline (JAWS_Protocol_Pipeline *pp)
-{
-  this->insert (pp);
-}
-
-JAWS_Protocol_Pipeline::~JAWS_Protocol_Pipeline (void)
-{
-}
-
-int
-JAWS_Protocol_Pipeline::pull (ACE_Message_Block &mb)
-{
-  int result = 0;
-
-  if (this->prev_pipe () != 0)
-    result = this->prev_pipe ()->pull (mb);
-
-  if (result == 0)
-    result = this->pull_hook (mb);
-
-  return result;
-}
-
-int
-JAWS_Protocol_Pipeline::push (ACE_Message_Block &mb)
-{
-  int result = 0;
-
-  if (result == 0)
-    result = this->push_hook (mb);
-
-  if (this->next_pipe () != 0)
-    result = this->next_pipe ()->push (mb);
-
-  return result;
-}
-
-int
-JAWS_Protocol_Pipeline::init (int, char *[])
-{
-  return 0;
-}
-
-int
-JAWS_Protocol_Pipeline::fini (void)
-{
-  return 0;
-}
-
-void
-JAWS_Protocol_Pipeline::insert (JAWS_Protocol_Pipeline *pp)
-{
-  if (pp == 0)
-    return;
-
-  if (this->prev_pipe () != 0)
-    this->prev_pipe ()->append (pp);
-  pp->append (this);
-}
-
-void
-JAWS_Protocol_Pipeline::append (JAWS_Protocol_Pipeline *pp)
-{
-  if (pp == 0)
-    return;
-
-  JAWS_Protocol_Pipeline *p;
-  for (p = this; p->next_pipe () != 0; p = p->next_pipe ())
-    ;
-  p->next_pipe (pp);
-  pp->prev_pipe (p);
-}
-
-JAWS_Protocol_Pipeline *
-JAWS_Protocol_Pipeline::prev_pipe (JAWS_Protocol_Pipeline *)
-{
-  return 0;
-}
-
-JAWS_Protocol_Pipeline *
-JAWS_Protocol_Pipeline::next_pipe (JAWS_Protocol_Pipeline *)
-{
-  return 0;
-}
-
-JAWS_Protocol_Filter::JAWS_Protocol_Filter (void)
-  : prev_pipe_ (0),
-    next_pipe_ (0)
-{
-}
-
-JAWS_Protocol_Filter::JAWS_Protocol_Filter (JAWS_Protocol_Pipeline *pp)
-  : JAWS_Protocol_Pipeline (pp),
-    prev_pipe_ (0),
-    next_pipe_ (0)
-{
-}
-
-JAWS_Protocol_Filter::~JAWS_Protocol_Filter (void)
-{
-}
-
-void
-JAWS_Protocol_Filter::add (JAWS_Protocol_Pipeline *component)
-{
-  JAWS_Protocol_Pipeline::insert (component);
-}
-
-JAWS_Protocol_Pipeline *
-JAWS_Protocol_Filter::prev_pipe (JAWS_Protocol_Pipeline *pp)
-{
-  if (pp != 0)
-    this->prev_pipe_ = pp;
-
-  return this->prev_pipe_;
-}
-
-JAWS_Protocol_Pipeline *
-JAWS_Protocol_Filter::next_pipe (JAWS_Protocol_Pipeline *pp)
-{
-  if (pp != 0)
-    this->next_pipe_ = pp;
-
-  return this->next_pipe_;
-}
diff --git a/apps/JAWS/server/Pipeline.h b/apps/JAWS/server/Pipeline.h
deleted file mode 100644
index f004d149f2b..00000000000
--- a/apps/JAWS/server/Pipeline.h
+++ /dev/null
@@ -1,198 +0,0 @@
-/* -*- c++ -*- */
-// $Id$
-
-#include "ace/Message_Block.h"
-#include "ace/Service_Object.h"
-
-
-class JAWS_Protocol_Pipeline : public ACE_Service_Object
-// = TITLE
-//     This is intended to be the base class of pipeline
-//     components.
-//
-{
-public:
-  JAWS_Protocol_Pipeline (void);
-  JAWS_Protocol_Pipeline (JAWS_Protocol_Pipeline *pp);
-
-  virtual ~JAWS_Protocol_Pipeline (void);
-
-  int pull (ACE_Message_Block &mb);
-  // Method that initiates the work.
-
-  int push (ACE_Message_Block &mb);
-  // Method that notifies work is available.
-
-  virtual int pull_hook (ACE_Message_Block &mb) = 0;
-  // Required method that finishes the work.
-
-  virtual int push_hook (ACE_Message_Block &mb) = 0;
-  // Required method that accepts available work.
-
-
-  virtual int init (int, char *[]);
-  virtual int fini (void);
-  // Service Object initialization and finalization
-
-protected:
-  void insert (JAWS_Protocol_Pipeline *pp);
-  void append (JAWS_Protocol_Pipeline *pp);
-
-  virtual JAWS_Protocol_Pipeline * prev_pipe (JAWS_Protocol_Pipeline *pp = 0);
-  // Virtual accessor to the preceding pipeline component
-
-  virtual JAWS_Protocol_Pipeline * next_pipe (JAWS_Protocol_Pipeline *pp = 0);
-  // Virtual accessor to the succeding pipeline component
-
-};
-
-class JAWS_Protocol_Filter : public JAWS_Protocol_Pipeline
-// = TITLE
-//     This is intended to be the task skeleton of pipeline
-//     components.
-//
-{
-public:
-  JAWS_Protocol_Filter (void);
-  JAWS_Protocol_Filter (JAWS_Protocol_Pipeline *pp);
-  // Constructors
-
-  virtual ~JAWS_Protocol_Filter (void);
-  // Destructor
-
-  void add (JAWS_Protocol_Pipeline *component);
-  // Insert a pipeline component into the pipeline chain
-
-  virtual int pull_hook (ACE_Message_Block &mb) = 0;
-  // Required method that finishes the work.
-
-  virtual int push_hook (ACE_Message_Block &mb) = 0;
-  // Required method that accepts available work.
-
-private:
-  virtual JAWS_Protocol_Pipeline * prev_pipe (JAWS_Protocol_Pipeline *pp = 0);
-  // Virtual accessor to the preceding pipeline component
-
-  virtual JAWS_Protocol_Pipeline * next_pipe (JAWS_Protocol_Pipeline *pp = 0);
-  // Virtual accessor to the succeding pipeline component
-
-protected:
-  JAWS_Protocol_Pipeline *prev_pipe_;
-  // The preceeding element in the pipeline chain.
-  JAWS_Protocol_Pipeline *next_pipe_;
-  // The succeeding element in the pipeline chain.
-};
-
-
-/*
-  This file describes the interfaces to the protocol pipeline
-  abstraction for JAWS.  To understand how this is to work, let's
-  examine the processing path of a Web server.
-
-  CLIENT                          SERVER
-  +--------------.--------------+ +---------------.----------------+
-  |Issue Request |Display File  | |Retrieve File  |Receive Request |
-  +--------------^--------------+ +---------------^----------------+
-   11111111111111 66666666666666   333333333333333 2222222222222222
-                 +--------------+ +---------------+
-                 |Receive File  | |Send File      |
-                 +--------------+ +---------------+
-                  55555555555555   444444444444444
-
-  That is, a client issues a request.  The server receives it, returns
-  content back to the client.  The client then displays the content.
-
-  But, this ignores issues which surround processing of the content.
-  As a simple example, consider the case when the client has limited
-  screen real-estate and limited colors (as might be the case with
-  PDAs).  Then, when the content involves an image, the processing
-  path involve the following additional stages:
-
-  CLIENT                          SERVER
-  +--------------.--------------+ +---------------.----------------+
-  |Issue Request |Display File  | |Retreive File  |Receive Request |
-  +--------------^--------------+ +---------------^----------------+
-   11111111111111 88888888888888   333333333333333 2222222222222222
-                 +--------------+ +---------------+
-                 |Dither Image  | |Send File      |
-                 +--------------+ +---------------+
-                  77777777777777   444444444444444
-                 +--------------+
-                 |Scale Image   |
-                 +--------------+
-                  66666666666666
-                 +--------------+
-                 |Receive File  |
-                 +--------------+
-                  55555555555555
-
-  After the server returns the content of the image to the client, the
-  client must scale the image to fit on its display device and then
-  dither the image to the number of colors which its display device
-  can support.
-
-  However, for a PDA with limited resources for battery life and
-  computation time, this may not be the optimal path for the file to
-  follow to achieve the best possible performance.  For instance, due
-  to the bandwidth available to the PDA client, it may be better if
-  the server were to scale the image instead.  In this case, the path
-  for the requested image would be viewed as the following:
-
-  CLIENT                          SERVER
-  +--------------.--------------+ +---------------.----------------+
-  |Issue Request |Display File  | |Retreive File  |Receive Request |
-  +--------------^--------------+ +---------------^----------------+
-   11111111111111 88888888888888   333333333333333 2222222222222222
-                 +--------------+ +---------------+
-                 |Dither Image  | |Scale File     |
-                 +--------------+ +---------------+
-                  77777777777777   444444444444444
-                 +--------------+ +---------------+
-                 |Receive File  | |Send File      |
-                 +--------------+ +---------------+
-                  66666666666666   555555555555555
-
-  The purpose of Pipeline is to provide a framework which allows for
-  this kind of negotiation to occur between a client and the server.
-  The protocol by which the client and server negotiate with each
-  other is left as an open issue.  Solutions that can be used may
-  include use of special headers which identify which actions a client
-  would like the server to perform, or through PEP, the protocol
-  negotiation protocol.
-
- */
-
-// Ok, let's figure out an interface that's going to work.
-
-// These pipeline components should provide a method that allows me to
-// chain a bunch of them together and then with a single method call,
-// have data.
-
-// The usual semantics of programatic pipelines like ours is that the
-// first component makes a complete pass over the input before sending
-// it to the next component.  This seems like a reasonable semantic,
-// but we can do some refinements.
-
-// First, we do not want the hand-off of data to involve copying the
-// data from the previous component to the next.  This implies that
-// between two consecutive components is a shared buffer.  However, it
-// is wasteful to have N+1 buffers for N pipeline components if the
-// pipelines are going to be processing the input serially.  This
-// leads to the conclusion that only two buffers are necessary for the
-// pipeline.
-
-// Second, we need to decide how to specify the makeup or
-// functionality of the protocol pipeline.  In UNIX, this is done by
-// the command line with "|" symbols between components.  We too could
-// use strings.
-
-// Third, we need to decide how to build of these protocol pipelines.
-// We may wish for static definitions to be constructed ala the
-// Service Configurator.  This implies that the Protocol Pipeline
-// Factory is a Service Object, and it can accept a string which
-// describes the components of the pipeline.  Since we are using
-// strings, it seems that each of the pipeline components themselves
-// could also be considered Service Objects to be dynamically loaded.
-// However, to maintain some notion of type safety, these pipeline
-// components should probably have their own separate Configurator, so
-// a Protocol Pipeline Configurator should be created.