Eventmachine talk - May 2006 - an idea to improve eventmachine calculating

Hello,

actually my server just works in a way where user objects interact
which each other by using a controller object to make decisions. If
it is a bot the controller is just the AI calculating the proper
reaction, if it is a remote user the controller is the connection to
the client so the user gets the necessary information to act
accordingly. Hopefully I''ll be able in the nearer future to publish
the server as a project on rubyforge and maybe discuss that design
with interested people.

Anyway, I''d prefer to set the userManager class or object from
outside so it is not hard coded into the module. I''d like to extend
the Connection class just in a way it is usable in a black box-like
way so it is just accomplishing its purpose and you don''t have to
mess with it any further. Actually I am just a fan of this unix
philosophy with using tools that do just on job but do it right (i.e.
grep) and don''t want to implement any protocol details directly
within EventMachine.

So I guess I am going to use that code to get the job done:

require ''rubygems''
require ''eventmachine''

include EventMachine

module EventMachine
	class Acceptable < Connection
		@@manager = false
		
		attr_writer :parent
		
		def self.userManager= manager
			@@manager = manager
		end
		
		def accept connection
			puts @@manager, connection
			@@manager.accept connection if @@manager.respond_to? :accept
		end
		
		def post_init
			accept self
		end
		
		def receive_data data
			@parent.receive data if @parent.respond_to? :receive
		end
	end
end

EventMachine::run {
	Acceptable.userManager = "any class or object with an accept
(connection) method"
	EventMachine::start_server "127.0.0.1", 8081, Acceptable
}



Now the code is usable as a module without internal changes. After
the userManager created the remote user object including the
connection, a reference to the user is stored in @parent and so he
can receive data sent over the connection.
Maybe this solution is now to problem specific but I thought the idea
of encapsulating the functionality and separating data handling from
data sending/receiving could be useful.


Regards, Sascha