[_] 47% Framework Requirements
	About
		This document summarizes the best ideas from the patterns document.
		The patterns document tries to enumerate all available options.
		The requirements document chooses which ones to actually use.
		A later specification document will attempt to reconcile the requirements into a syntax and semantics.
	Desirable Qualities
		Best practices should be encouraged.
			Base classes should set precedents for best practices.
			The design should encourage continued use of best practices.
		Substandard qualities should be possible but gently discouraged.
			People like to have options.
			People like to exercise those options, whether or not they're good.
			It's not the framework's duty to prevent people from doing what they want.
	Undesirable Qualities
		Avoid implicit constructs.
			Implicit constructs cause action without visible indication.
			They are disorienting.
			They interfere with comprehension.
		Avoid unnecessary magic.
			Magic is scary.
			It also implies action at a distance.
		Avoid cleverness.
			Cleverness leads to brittle design.
			It also leads to unnecessary magic.
			It also leads to implicit constructs.
		Avoid metaphors.
			Metaphors are harmful when writing abstract frameworks.
			Metaphors are useful tools for creating systems that mimic real things.
				When designed properly, metaphors provide conceptual and contextual information about a framework.
			Metaphors are contradictory to abstract design.
				Metaphors provide specific conceptual frameworks.
				System designs that fit within these frameworks are elegant.
				Systems that wish to use other concepts are generally awkward.
				Adapters can connect between metaphors, but they should not be needed.
	[_] 0% Documentation Requirements
		Many "requirements" are really recommended conventions.
		For example:
			If we require return values to be typed, or ignored.
			Obviously we can't force code to do that.
			So we document it.
		[_] 0% Style guide?
	[X] 100% Namespace Requirements
		[X] 100% Choose a short base name for the namespace.
			Large class names are unwieldy.
			Objects should be under a single top-level namespace.
				What single top-level namespace should be used?
				Bacon - Basic Asynchronous Cooperative Object Networks?
				Reflex <- chosen one
		[X] 100% Choose a relatively flat namespace for the framework.
			Excessive namespace nesting is unwieldy.
			The namespace should be organized.
			How should the namespace be organized?
	[_] 20% Class and Object Structural Requirements
		[X] 100% Support full object orientation.
			[X] 100% Support composition of smaller objects into larger ones (has-a).
			[X] 100% Support composition through direct inheritance.
			[X] 100% Support composition through class roles.
			[X] 100% Support composition through runtime watcher roles.
		[_] 0% Method parameters should follow a single standard.
			[_] 0% Methods should receive only two parameters.
				$self - The object being called.
				$message - A Message object, or a subclass.
				[_] 0% What about out-of-band information, such as other continuations?
					Additional parameters?
					Standard members of $message?
					Lexical magic?
						Not in the base.
						Maybe as an extension.
			[_] 0% Methods should standardize their return semantics.
				[_] 0% What are those semantics?
					Ignore return values?
					emit() as return?
				[_] 0% Returned messages must be typed.
		[_] 0% Function parameters should follow a single standard.
			[_] 0% What should that standard be?
		[_] 0% Procedural design should be supported.
			Some people will prefer procedural design.
			[_] Objects are their own condvars.
				$object->wait() waits for the object to finish/destruct.
		[_] 0% Determine whether "role" is a confusing name.
			Alternatives:
				part
					Interestingly ambiguous.
					Parts as in objects that assemble into other things.
					Parts as in roles or duties in the whole.
				duty
					Uninterestingly unambiguous.
					Dreary name.
					No longer than role or part.
				job
					Shortest alternative.
					Ambiguous, since "job" may mean a work unit.
					Perhaps drearier than duty.
				Not: responsibility
					Too long.
					Res. or resp. are ambiguous abbreviations.
	[X] 100% Object Containership Composition Rules
		[X] 100% Containership rules are delegated to the objects themselves.
		[X] 100% Runtime roles may be assigned as part of the observation, not the sub-object.
			[X] 100% Multiple watchers may have the same runtime role.
				This is already possible.
				Currently roles address watchers.
				Multiple watchers for a role requires additional addressing.
				Possibly passing the watcher object into the callback.
				[X] 100% Implement a _sender parameter supplied by Reflex::Role::Object.
			[X] 100% Default handler method names may be derived from roles and message types.
				Sender is a DNS resolver.
				Sender's role is "resolver".
				Sender emits a "success" event.
				Container may define an on_resolver_success() method to handle the event.
		[X] 100% Methods
			[X] 100% Containership methods are defined by Moose traits.
				[X] 100% Moose Observer trait implies that the stored object will be observed by the owner.
				[X] 100% Moose Emitter trait implies that changing the attribute emits an event to observers.
				[X] 100% Moose introspection allows objects to find their contents.
	[X] 100% Class Inheritance Rules
		[X] 100% Class inheritance rules are delegated to Moose.
	[_] 20% Messaging Requirements
		[_] 0% Object command interfaces must be methods.
			[_] 0% Methods on the objects themselves may pass messages into themselves.
				Synchronous method calls are translated into asynchronous messages.
			[_] 0% Methods on the objects may trigger activity that emits new events.
				Synchronous actions may start or stop messages emitted by an object.
			[_] 0% Objects may be interfaces (proxies) that pass messages to other objects.
				Objects may act as interfaces to local or remote services.
				Synchronous method calls are translated into asynchronous messages.
		[_] 0% Local accessors and simple mutators must be synchronous.
			Messages for local accessors and mutators is unnecessary overhead.
		[_] 44% Objects must be permitted to emit messages into their containers.
			[_] 0% Message emission is optional, depending on the use case.
				[_] 0% Define a use case where message emission is required.
				[_] 0% Define a use case where it's not.
			[_] 83% Emitted messages are first handled by the object emitting them.
				[X] 100% Subclasses may handle messages emitted by base classes.
				[X] 100% Subclasses may emit new messages.
				[_] 50% Subclasses may emit the same message without re-catching it.
					Implies that events bubble out of the object.
					Base class emits, and subclasses pass it outward.
					[X] 100% Implement as small methods that re-emit events.
						Easy to implement.
						Tedious, because you have to implement one for every event.
						Slow because of the extra method indirection.
					[_] 0% Implement some kind of event mapping.
						Hard to implement.
						Syntactically messy because the mapping must be made explicit.
							This could probably be cleaned up later.
						Faster since it avoids the indirection.
			[_] 50% Emitted messages are next handled by explicit and role-based observers.
				[_] 0% Explicit observers.
				[X] 100% Role-based observers.
		[_] 60% All forms of message handler (callback) must be supported.
			[X] 100% Anonymous Coderefs
				Anonymous coderefs support closures.
				Anonymous coderefs and closures may be used to implement faux continuation passing style.
				[X] Simple.
					my $t = Reflex::Timer->new( ..., on_event => \&coderef );
				[X] Observer.
					$object->watch( watched => $object, event => "name", callback => \&coderef );
				[X] Traits.
					has member => ( traits => ['Reflex::Trait::Observed'] );
			[_] 0% Named Subroutine References
				Named message handlers are exportable as reusable interfaces.
				[_] TODO - What is this?
			[X] 100% Object Methods
				Is this not obvious?
				[X] Simple.
					my $t = Reflex::Timer->new( ..., on_event => rcb_method($watcher, "method_name") );
				[X] Observer (array).
					my $t = Reflex::Timer->new( ..., on_event => rcb_object($watcher, \@methods) );
				[X] Observer (hash).
					my $t = Reflex::Timer->new( ..., on_event => rcb_object($watcher, \%methods) );
				Traits not supported at this time.
			[_] 0% Class Methods
				Classes may be used as singletons.
				[_] 0% Do we want to support this?
			[X] 100% Promises or condvars.
		[_] 0% Messages must be associated with their triggers.
			[_] 0% One message may trigger another, inner message.
				[_] 0% The inner message must be associated with the outer message.
					If object represent tasks, then messages are not needed.
					[_] 0% Do objects represent tasks?
				[_] 0% Canceling the outer message must trigger cancelation of all associated inner messages.
				[_] 0% Generally, all inner messages should complete before an outer message completes.
					This emulates asynchronous call/return semantics for messages.
					Task coordination is simplified.
	[_] 50% Session Location Rules
		[X] 100% Objects may be created in the same session as the creator.
		[_] 0% Objects may be created in new sessions, separate from the creator.
			[_] 0% New sessions may be started in the same process as the previous one.
			[_] 0% New sessions may be started in new threads.
				[_] 0% Investigate whether we want to support threads.
					Threads support may be more efficient on Windows.
					Perhaps transparently thread/fork depending on $^O.
			[_] 0% New sessions may be started in other processes.
				[_] 0% Processes may be forked at session creation time.
					Caveat: The new session is executed in isolation.
				[_] 0% Processes may be already established and attached to.
			[_] 0% Consider POE::Component::IKC for the backbone between processes.
			[_] 0% Consider MDNS for finding objects.
	[_] 0% Continuation Rules
		[_] 0% Continuations may be associated with objects.
			$self is such a continuation.
			[_] 0% Object-scoped resources (watchers, etc) should be stored in the object's continuation.
				[_] 0% Object destruction triggers associated resource cleanup.
		[_] 0% Continuations may be associated with messages.
			[_] 0% A message's sender and receiver may have their own continuations associated with the message.
			[_] 0% Data stored in the sender's continuation is not visible to the receiver.
			[_] 0% Receiver data is not visible to the sender.
			[_] 0% Message-scoped resources should be stored in the message's continuation.
				[_] 0% Message cancelation triggers associated resource cleanup.
	[_] 48% Common primitive classes must be provided.
		[_] 27% Low-level event watchers.
			[_] 50% Reflex::Handle
				[X] 100% Strawman implementation.
				[_] 0% Determine API.
			[_] 16% Reflex::Timer
				[_] 50% Delay a number of seconds.
					[X] 100% Repeat with drift.
					[_] 0% Repeat without drift.
				[_] 0% Wait for a specific time.
					[_] 0% Repeat without drift.
					[_] 0% Use DateTime for interval math.
				[_] 0% Determine full API.
			[_] 0% Reflex::Cron
				[_] 0% Strawman implementation.
				[_] 0% Determine API.
					See POE::Component::Cron for clues.
					Would Chris Fedde like to work on this?
				[_] 0% Wait for repeating times.
			[_] 50% Reflex::Signal
				[X] 100% Strawman implementation.
				[_] 0% Determine API.
			[_] 50% Reflex::PID (SIGCHLD)
				[X] 100% Strawman implementation.
				[_] 0% Determine API.
			[_] 0% What else?
		[_] 19% Primitive program pieces.
			[_] 0% Reflex::App
				[_] 0% Strawman implementation.
				[_] 0% Determine API.
			[_] 20% Reflex::Client::HTTP
				[_] 33% Reflex::Connector
					[X] 100% Strawman implementation.
					[_] 0% Determine API.
					[_] 0% IPv6 support.
				[_] 0% Reflex::Connector::Keepalive
					[_] 0% Strawman implementation.
					[_] 0% Determine API.
				[_] 0% Reflex::Resolver
					[_] 0% Determine API.
					[_] 0% Determine how to make asynchronous.
						Forked?
						Coro?
						Threads?
					[_] 0% IPV4
					[_] 0% IPv6
				[_] 50% Reflex::Stream
					[X] 100%Strawman implementation.
					[_] 0% Determine API.
					Use Data::Transform internally to parse & marshall data.
			[_] 33% Reflex::Listener
				[X] 100% Strawman implementation.
				[_] 0% Determine API.
					See POE::Wheel::ListenAccept for clues.
				[_] 0% IPv6 support.
			[_] 0% Reflex::Process
				[_] 0% Strawman implementation.
				[_] 0% Determine API.
					See POE::Wheel::Run for clues.
			[_] 0% Reflex::UdpPeer
				[_] 0% Strawman implementation.
				[_] 0% Determine API.
			[_] 0% Reflex::Tail
				[_] 0% Strawman implementation.
				[_] 0% Determine API.
					See POE::Wheel::FollowTail for clues.
			[X] 100% Reflex::Collection
				Manage a collection of Reflex objects.
				Removes objects from itself when they shut down.
				Reflex servers can use this to manage client objects.
			[_] 0% What else?  Probably a lot!
		[X] 100% POE Interfaces
			[X] 100% Wheel wrappers.
				[X] 100% Reflex::POE::Wheel
					Generic base class for POE::Wheel watchers.
				[X] 100% Reflex::POE::Wheel::Run
					Specific subclass for proving the concept.
			[X] 100% Generic Component shims.
				[X] 100% Create a postback analog for components that expect postbacks.
					Reflex::POE::Postback
					About
						Creates a coderef that, when called, posts a message to the object's session, with routing information back to the object.
						Postbacks use closures to pass @passthru_params to the callback.
						Closures can also handle routing information.
						Usage syntax must be identical to Reflex postbacks.
						Creation syntax may differ from Reflex postbacks.
							Identical creation syntax would be to allow others to create them for us.
							However, most eternal postback creators use $_[SENDER]->postback().
							$_[SENDER] is the Reflex object's session, not an individual object.
							Therefore, components that call $_[SENDER]->postback() will not work.
							Therefore, $_[SENDER]->postback() syntax is not needed.
						To support identical creation syntax.
							$_[SENDER] must be a session that maps directly to a single object.
							It could be a dynamically created session for the purpose of interfacing.
							Indirection would be heavy.
							Consider it for a future revision.
				[X] 100% Create an event analog for components that expect events.
					About
						Many components allow callers to specify return events.
						We create a unique, anonymous event that calls a specific object and method upon dispatch.
						We can pass this event to components that expect them.
					Syntax if anonymous events may be blessed objects
						my $event = Reflex::POE::Event->new(...);
						$_[KERNEL]->post($event, @callback_params);
					Syntax if events may not be blessed
						About
							Some explicit cleanup must be provided and adhered to.
							Rely on object DEMOLISH to automatically clean up for us.
							CAVEAT: Components that stringify event names will fail.
						Sorry, but they must be blessed for now.
							The bless and DEMOLISH tracking is very convenient.
							I haven't found a good, reliable way to avoid it.
					Dispatch Mechanism
						_default
							Events that are objects in the Reflex::POE::Event class are invoked to deliver themselves.
				[X] 100% Session subscription.
					About
						A client Reflex object creates the component, to be used as a service.
						The client Reflex object registers interest in the service's events.
						The service's events are posted to all interested Reflex objects.
						POE::Component::IRC will be a good example component.
					Syntax
						Reflex::POE::Session watcher.
					Dispatch Mechanism
						Sender Interest
							The object creates the component.
							The object registers interest in all events from the component.
				[X] 100% Components that emit specific events require Wheel-like wrappers.
					[X] 100% Is this worth supporting?
						No.  The Session subscriber can detect any events emitted by the component.
	[_] 33% Optimizations.
		[X] 100% Only $kernel->call() when we need to switch sessions.
		[_] 0% Do we need call() at all?
			[_] 0% Explore IO::Lambda's cheat.
		[_] 0% Consolidate POE-specific code out into a single role.
			Allows other event loops to be supported directly rather than through POE.
