in reply to Node removed.

You may want to use the words "Publish" and "Subscribe" to document your implementation of the well-understood "publish/subscribe model".

Depending on your audience, you may want to give your API more of an OO feel:

use Dispatcher qw(RequestDispatch ReadData SendData); my $d = new Dispatcher({host => "192.168.1.1",port => "1440"}, "data1", "data2", "data3"); foreach my $type (qw(data1 data2 data3)) { print "RECIEVED for ", $d->read()->type , "\n\n"; # $d->read returns a Dispatcher::Record object, which + has a "type" } my $rec = $d->NewRecord({type=>"data4"}); # Returns a Dispatch +er::Record object associated with $d $rec->send ("DATA"); # The Record already know what port, serv +er, and type to use. $d->Port (1440); $rec->send("More Data on port 1440");
Aoother suggestion is to used one of the canned POE wheels to implement your server. That way, your code becomes scalable, using multiple threads.

Compliments on the clean code!

     "Choose a job you like and you will never have to work a day of your life" - Confucius

Replies are listed 'Best First'.
Re^2: RFC: dispatcher UPDATED, now comes with API
by Trizor (Pilgrim) on Apr 08, 2007 at 17:32 UTC

    Well thats what I get for coding in a cave. I'll implement something without knowing a pre-defined name and where to look. I did look at POE, but one of my goals is minimal dependancy, hence only using Config::Tiny, and I may make Config::Tiny optional and take extended config in the command line.

    The OO is a good idea, though the original batch processing system this is meant for was coded in a highly procedural style and I'd like to keep it that way, I'll make an OO version for other releases.