eventmachine 0.12.10-x86-mswin32-60 → 1.0.0.beta.2-x86-mswin32-60

data/lib/em/messages.rb

@@ -1,66 +1,66 @@
-#--
-#
-# Author:: Francis Cianfrocca (gmail: blackhedd)
-# Homepage::  http://rubyeventmachine.com
-# Date:: 16 Jul 2006
-# 
-# See EventMachine and EventMachine::Connection for documentation and
-# usage examples.
-#
-#----------------------------------------------------------------------------
-#
-# Copyright (C) 2006-07 by Francis Cianfrocca. All Rights Reserved.
-# Gmail: blackhedd
-# 
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of either: 1) the GNU General Public License
-# as published by the Free Software Foundation; either version 2 of the
-# License, or (at your option) any later version; or 2) Ruby's License.
-# 
-# See the file COPYING for complete licensing information.
-#
-#---------------------------------------------------------------------------
-#
-# 
-
-=begin
-
-Message Routing in EventMachine.
-
-The goal here is to enable "routing points," objects that can send and receive
-"messages," which are delimited streams of bytes. The boundaries of a message
-are preserved as it passes through the reactor system.
-
-There will be several module methods defined in EventMachine to create route-point
-objects (which will probably have a base class of EventMachine::MessageRouter
-until someone suggests a better name).
-
-As with I/O objects, routing objects will receive events by having the router
-core call methods on them. And of course user code can and will define handlers
-to deal with events of interest.
-
-The message router base class only really needs a receive_message method. There will
-be an EM module-method to send messages, in addition to the module methods to create
-the various kinds of message receivers.
-
-The simplest kind of message receiver object can receive messages by being named 
-explicitly in a parameter to EM#send_message. More sophisticated receivers can define
-pub-sub selectors and message-queue names. And they can also define channels for
-route-points in other processes or even on other machines.
-
-A message is NOT a marshallable entity. Rather, it's a chunk of flat content more like
-an Erlang message. Initially, all content submitted for transmission as a message will
-have the to_s method called on it. Eventually, we'll be able to transmit certain structured
-data types (XML and YAML documents, Structs within limits) and have them reconstructed
-on the other end.
-
-A fundamental goal of the message-routing capability is to interoperate seamlessly with
-external systems, including non-Ruby systems like ActiveMQ. We will define various protocol
-handlers for things like Stomp and possibly AMQP, but these will be wrapped up and hidden
-from the users of the basic routing capability.
-
-As with Erlang, a critical goal is for programs that are built to use message-passing to work
-WITHOUT CHANGE when the code is re-based on a multi-process system.
-
-=end
-
+#--
+#
+# Author:: Francis Cianfrocca (gmail: blackhedd)
+# Homepage::  http://rubyeventmachine.com
+# Date:: 16 Jul 2006
+# 
+# See EventMachine and EventMachine::Connection for documentation and
+# usage examples.
+#
+#----------------------------------------------------------------------------
+#
+# Copyright (C) 2006-07 by Francis Cianfrocca. All Rights Reserved.
+# Gmail: blackhedd
+# 
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of either: 1) the GNU General Public License
+# as published by the Free Software Foundation; either version 2 of the
+# License, or (at your option) any later version; or 2) Ruby's License.
+# 
+# See the file COPYING for complete licensing information.
+#
+#---------------------------------------------------------------------------
+#
+# 
+
+=begin
+
+Message Routing in EventMachine.
+
+The goal here is to enable "routing points," objects that can send and receive
+"messages," which are delimited streams of bytes. The boundaries of a message
+are preserved as it passes through the reactor system.
+
+There will be several module methods defined in EventMachine to create route-point
+objects (which will probably have a base class of EventMachine::MessageRouter
+until someone suggests a better name).
+
+As with I/O objects, routing objects will receive events by having the router
+core call methods on them. And of course user code can and will define handlers
+to deal with events of interest.
+
+The message router base class only really needs a receive_message method. There will
+be an EM module-method to send messages, in addition to the module methods to create
+the various kinds of message receivers.
+
+The simplest kind of message receiver object can receive messages by being named 
+explicitly in a parameter to EM#send_message. More sophisticated receivers can define
+pub-sub selectors and message-queue names. And they can also define channels for
+route-points in other processes or even on other machines.
+
+A message is NOT a marshallable entity. Rather, it's a chunk of flat content more like
+an Erlang message. Initially, all content submitted for transmission as a message will
+have the to_s method called on it. Eventually, we'll be able to transmit certain structured
+data types (XML and YAML documents, Structs within limits) and have them reconstructed
+on the other end.
+
+A fundamental goal of the message-routing capability is to interoperate seamlessly with
+external systems, including non-Ruby systems like ActiveMQ. We will define various protocol
+handlers for things like Stomp and possibly AMQP, but these will be wrapped up and hidden
+from the users of the basic routing capability.
+
+As with Erlang, a critical goal is for programs that are built to use message-passing to work
+WITHOUT CHANGE when the code is re-based on a multi-process system.
+
+=end
+

data/lib/em/process_watch.rb

@@ -1,44 +1,44 @@
-module EventMachine
-
-  # This is subclassed from EventMachine::Connection for use with the process monitoring API. Read the
-  # documentation on the instance methods of this class, and for a full explanation see EventMachine.watch_process.
-  class ProcessWatch < Connection
-    # :stopdoc:
-    Cfork = 'fork'.freeze
-    Cexit = 'exit'.freeze
-    # :startdoc:
-
-    def receive_data(data) # :nodoc:
-      case data
-      when Cfork
-        process_forked
-      when Cexit
-        process_exited
-      end
-    end
-
-    # Returns the pid that EventMachine::watch_process was originally called with.
-    def pid
-      @pid
-    end
-
-    # Should be redefined with the user's custom callback that will be fired when the prcess is forked.
-    #
-    # There is currently not an easy way to get the pid of the forked child.
-    def process_forked
-    end
-
-    # Should be redefined with the user's custom callback that will be fired when the process exits.
-    #
-    # stop_watching is called automatically after this callback
-    def process_exited
-    end
-
-    # Discontinue monitoring of the process.
-    # This will be called automatically when a process dies. User code may call it as well.
-    def stop_watching
-      EventMachine::unwatch_pid(@signature)
-    end
-  end
-
+module EventMachine
+
+  # This is subclassed from EventMachine::Connection for use with the process monitoring API. Read the
+  # documentation on the instance methods of this class, and for a full explanation see EventMachine.watch_process.
+  class ProcessWatch < Connection
+    # :stopdoc:
+    Cfork = 'fork'.freeze
+    Cexit = 'exit'.freeze
+    # :startdoc:
+
+    def receive_data(data) # :nodoc:
+      case data
+      when Cfork
+        process_forked
+      when Cexit
+        process_exited
+      end
+    end
+
+    # Returns the pid that EventMachine::watch_process was originally called with.
+    def pid
+      @pid
+    end
+
+    # Should be redefined with the user's custom callback that will be fired when the prcess is forked.
+    #
+    # There is currently not an easy way to get the pid of the forked child.
+    def process_forked
+    end
+
+    # Should be redefined with the user's custom callback that will be fired when the process exits.
+    #
+    # stop_watching is called automatically after this callback
+    def process_exited
+    end
+
+    # Discontinue monitoring of the process.
+    # This will be called automatically when a process dies. User code may call it as well.
+    def stop_watching
+      EventMachine::unwatch_pid(@signature)
+    end
+  end
+
 end

data/lib/em/protocols.rb

@@ -5,7 +5,7 @@ module EventMachine
   # - Memcache
   # - SmtpClient and SmtpServer
   # - SASLauth and SASLauthclient
-  # - LineAndTextProtocol and LineText2
+  # - LineProtocol, LineAndTextProtocol and LineText2
   # - HeaderAndContentProtocol
   # - Postgres3
   # - ObjectProtocol

data/lib/em/protocols/header_and_content.rb

@@ -1,138 +1,138 @@
-#--
-#
-# Author:: Francis Cianfrocca (gmail: blackhedd)
-# Homepage::  http://rubyeventmachine.com
-# Date:: 15 Nov 2006
-# 
-# See EventMachine and EventMachine::Connection for documentation and
-# usage examples.
-#
-#----------------------------------------------------------------------------
-#
-# Copyright (C) 2006-07 by Francis Cianfrocca. All Rights Reserved.
-# Gmail: blackhedd
-# 
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of either: 1) the GNU General Public License
-# as published by the Free Software Foundation; either version 2 of the
-# License, or (at your option) any later version; or 2) Ruby's License.
-# 
-# See the file COPYING for complete licensing information.
-#
-#---------------------------------------------------------------------------
-#
-#
-
-module EventMachine
-  module Protocols
-
-    # === Usage
-    #
-    #  class RequestHandler < EM::P::HeaderAndContentProtocol
-    #    def receive_request headers, content
-    #      p [:request, headers, content]
-    #    end
-    #  end
-    #
-    #  EM.run{
-    #    EM.start_server 'localhost', 80, RequestHandler
-    #  }
-    #
-    #--
-    # Originally, this subclassed LineAndTextProtocol, which in
-    # turn relies on BufferedTokenizer, which doesn't gracefully
-    # handle the transitions between lines and binary text.
-    # Changed 13Sep08 by FCianfrocca.
-    class HeaderAndContentProtocol < Connection
-      include LineText2
-
-      ContentLengthPattern = /Content-length:\s*(\d+)/i
-
-      def initialize *args
-        super
-        init_for_request
-      end
-
-      def receive_line line
-        case @hc_mode
-        when :discard_blanks
-          unless line == ""
-            @hc_mode = :headers
-            receive_line line
-          end
-        when :headers
-          if line == ""
-            raise "unrecognized state" unless @hc_headers.length > 0
-            if respond_to?(:receive_headers)
-              receive_headers @hc_headers
-            end
-            # @hc_content_length will be nil, not 0, if there was no content-length header.
-            if @hc_content_length.to_i > 0
-              set_binary_mode @hc_content_length
-            else
-              dispatch_request
-            end
-          else
-            @hc_headers << line
-            if ContentLengthPattern =~ line
-              # There are some attacks that rely on sending multiple content-length
-              # headers. This is a crude protection, but needs to become tunable.
-              raise "extraneous content-length header" if @hc_content_length
-              @hc_content_length = $1.to_i
-            end
-            if @hc_headers.length == 1 and respond_to?(:receive_first_header_line)
-              receive_first_header_line line
-            end
-          end
-        else
-          raise "internal error, unsupported mode"
-        end
-      end
-
-      def receive_binary_data text
-        @hc_content = text
-        dispatch_request
-      end
-
-      def dispatch_request
-        if respond_to?(:receive_request)
-          receive_request @hc_headers, @hc_content
-        end
-        init_for_request
-      end
-      private :dispatch_request
-
-      def init_for_request
-        @hc_mode = :discard_blanks
-        @hc_headers = []
-        # originally was @hc_headers ||= []; @hc_headers.clear to get a performance
-        # boost, but it's counterproductive because a subclassed handler will have to
-        # call dup to use the header array we pass in receive_headers.
-
-        @hc_content_length = nil
-        @hc_content = ""
-      end
-      private :init_for_request
-
-      # Basically a convenience method. We might create a subclass that does this
-      # automatically. But it's such a performance killer.
-      def headers_2_hash hdrs
-        self.class.headers_2_hash hdrs
-      end
-
-      class << self
-        def headers_2_hash hdrs
-          hash = {}
-          hdrs.each {|h|
-            if /\A([^\s:]+)\s*:\s*/ =~ h
-              tail = $'.dup
-              hash[ $1.downcase.gsub(/-/,"_").intern ] = tail
-            end
-          }
-          hash
-        end
-      end
-
-    end
-  end
-end
+#--
+#
+# Author:: Francis Cianfrocca (gmail: blackhedd)
+# Homepage::  http://rubyeventmachine.com
+# Date:: 15 Nov 2006
+# 
+# See EventMachine and EventMachine::Connection for documentation and
+# usage examples.
+#
+#----------------------------------------------------------------------------
+#
+# Copyright (C) 2006-07 by Francis Cianfrocca. All Rights Reserved.
+# Gmail: blackhedd
+# 
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of either: 1) the GNU General Public License
+# as published by the Free Software Foundation; either version 2 of the
+# License, or (at your option) any later version; or 2) Ruby's License.
+# 
+# See the file COPYING for complete licensing information.
+#
+#---------------------------------------------------------------------------
+#
+#
+
+module EventMachine
+  module Protocols
+
+    # === Usage
+    #
+    #  class RequestHandler < EM::P::HeaderAndContentProtocol
+    #    def receive_request headers, content
+    #      p [:request, headers, content]
+    #    end
+    #  end
+    #
+    #  EM.run{
+    #    EM.start_server 'localhost', 80, RequestHandler
+    #  }
+    #
+    #--
+    # Originally, this subclassed LineAndTextProtocol, which in
+    # turn relies on BufferedTokenizer, which doesn't gracefully
+    # handle the transitions between lines and binary text.
+    # Changed 13Sep08 by FCianfrocca.
+    class HeaderAndContentProtocol < Connection
+      include LineText2
+
+      ContentLengthPattern = /Content-length:\s*(\d+)/i
+
+      def initialize *args
+        super
+        init_for_request
+      end
+
+      def receive_line line
+        case @hc_mode
+        when :discard_blanks
+          unless line == ""
+            @hc_mode = :headers
+            receive_line line
+          end
+        when :headers
+          if line == ""
+            raise "unrecognized state" unless @hc_headers.length > 0
+            if respond_to?(:receive_headers)
+              receive_headers @hc_headers
+            end
+            # @hc_content_length will be nil, not 0, if there was no content-length header.
+            if @hc_content_length.to_i > 0
+              set_binary_mode @hc_content_length
+            else
+              dispatch_request
+            end
+          else
+            @hc_headers << line
+            if ContentLengthPattern =~ line
+              # There are some attacks that rely on sending multiple content-length
+              # headers. This is a crude protection, but needs to become tunable.
+              raise "extraneous content-length header" if @hc_content_length
+              @hc_content_length = $1.to_i
+            end
+            if @hc_headers.length == 1 and respond_to?(:receive_first_header_line)
+              receive_first_header_line line
+            end
+          end
+        else
+          raise "internal error, unsupported mode"
+        end
+      end
+
+      def receive_binary_data text
+        @hc_content = text
+        dispatch_request
+      end
+
+      def dispatch_request
+        if respond_to?(:receive_request)
+          receive_request @hc_headers, @hc_content
+        end
+        init_for_request
+      end
+      private :dispatch_request
+
+      def init_for_request
+        @hc_mode = :discard_blanks
+        @hc_headers = []
+        # originally was @hc_headers ||= []; @hc_headers.clear to get a performance
+        # boost, but it's counterproductive because a subclassed handler will have to
+        # call dup to use the header array we pass in receive_headers.
+
+        @hc_content_length = nil
+        @hc_content = ""
+      end
+      private :init_for_request
+
+      # Basically a convenience method. We might create a subclass that does this
+      # automatically. But it's such a performance killer.
+      def headers_2_hash hdrs
+        self.class.headers_2_hash hdrs
+      end
+
+      class << self
+        def headers_2_hash hdrs
+          hash = {}
+          hdrs.each {|h|
+            if /\A([^\s:]+)\s*:\s*/ =~ h
+              tail = $'.dup
+              hash[ $1.downcase.gsub(/-/,"_").intern ] = tail
+            end
+          }
+          hash
+        end
+      end
+
+    end
+  end
+end