Main base class for controllers based in I/O
Version: 0.0.9WWW::Slides::Controller::Single is the main base class for controllers based in I/O.
License: Perl Artistic License
Operating System: Linux
# See WWW::Slides::Controller::STDIO out anyway...
my $IO_controller = WWW::Slides::Controller::Single->new(
in_handle => *STDIN,
out_handle => *STDOUT,
# Be sure to check WWW::Slides::Controller::TCP as well,
# life can be easier
my $listener = IO::Socket->new(LocalPort => $port, Listen => 1);
my $sock = $listener->accept();
my $TCP_controller = WWW::Slides::Controller::Single->new(
in_handle => $sock,
out_handle => $sock,
This module represents the main base class for building up controllers in the WWW::Slides system. It is able to interact with WS::Talk objects in order to pilot all the aspects of a talk (see the documentation for WWW::Slides::Talk for more info on this).
While not normally used directly, this class can still be useful when used on its own. The main interface is through two handles, one used for input commands, one for putting out messages regarding those commands. The two handles can be the same (as in the case of a TCP socket) or different (for example using the standard streams). Subclass normally only add the needed logic to automatically set those handles up, but they can expand functionalities, of course.
The WWW::System is talk-centric, i.e. the main object is (or should be) the WS::Talk one (it's also the only containing a run() method, so you have probably already worked this out). For these reasons, a generic Controller has two main interaction points:
* in the first place, it provides facility for registering/releasing a selector, i.e. an object that will be (hopefully) used like a IO::Select one (ok, 99.9% of the times it will be an IO::Select object). A WS::Talk uses an IO::Select object to keep track of all possible sources of input data (attendee inputs, controllers, etc.), so registering the selector allows the controller set the right bits in the selector itself.
While this may seem a bit contrived in our case, because there's only a single input handle to look after, with this mechanism the Controller interface is able to deal with the possibility that a controller handles, behind the scenes, multiple inputs. This is the case of WWW::Slides::Controller::Multiple and its main descendant WWW::Slides::Controller::TCP, so WS::Controller::Single is no exception and adheres to this interface.
* On the actual controlling side, it provides the execute_commands() method, that grabs input commands and (tries to) execute them on the WS::Talk object. This is where the actual work is done, where the remote API is implemented and so the piece of code that's actually reused without any addition. Any command addition, of course, is likely to extend this command.