Tanker version 0.021
====================

Tanker is (hopefully), a generic pipeline module for Perl.

Tanker allows you to construct asynchronous pipelines such that

               another client
                     |
       client ----.  |  .----- yet another
                  |  |  |
               .----------.
               | Generate |
               |  Request |
               '----------'
                    |
                    | <- pipeline plugin
                    | <- pipeline plugin
                    | <- pipeline plugin
                    |
               .----------.
               | Generate |
               | Response |
               '----------'
                    |
                   \'/
                    '

and requests can travel down the pipeline asynchronously.

i.e if one requests enters the pipeline and a plugin takes
a long time to complete then other requests can be passing
down the pipeline at the same time.

Essentially ... it works a bit like Apache. Requests get generated by
clients. Requests godown pipelines. Plugins (or handlers) can massage
the Request. At the end a Response is generated.

The RequestGenerators and ResponseHandlers are generic. Requests can be
generated by anything - you typing in stuff, SMS, IRC, Jabber, HTTP,
speech - as long as you write the RG. At the other end the reverse is
true, Responses can go to anywhere in much the same way. Infcat,
multiple Responses can be generated froma Request and the Response
doesn't have to go to the same place as the Request came from. Tanker
handles all the concurrency for you so that if a Request is taking a
long time to go down the pipeline then other Requests can be travelling
down it simultaneously.

So you could have IRC+Jabber+Email->Speech if you wanted. I'd quite ike
to write a webswerver :)

I'm looking for a bit of peer review and advice. Currently it uses a
forking model which I'm not sure is the right idea. Also there's a few
specifics about how response handlers are going to work that I haven't
got figured out.

For example, currently the IRC generator is a hack with lots of
hardcoded stuff and there's no way for a ResponseHandler to use the same
POE::Component::IRC kernel to post back to the same IRC channel under
the same nick.

Is this whole approach a dead end? Am I smoking crack. Anybody got any
good ideas?


-----------------------------------
INSTALLATION
-----------------------------------

To install this module type the following:

   perl Makefile.PL
   make
   make test
   make install

Remember peeps, It's bad to do 'make test' as root. In fact, try to do as 
little as possible as root. Only do the 'make install' as root. Root is bad. 
Root is scary. Tree pretty. Beer Foamy. Fire bad.

You have been warned.

-----------------------------------
DEPENDENCIES
-----------------------------------

This module requires these other modules and libraries:

Data::Dumper
Net::IRC
POE::Component::IRC
POE

-----------------------------------
FAQ
-----------------------------------



- Why Tanker instead of say Juniper or Gin or whatever?
Because this could be a generic pipeline module (although I noted that
James uploaded somestuff yesterday as well, vive la differnce :) and
Tanker fits in with both Pipelines *and* Gin (as in Tanqueray). The
point being that you'd build a bot called Juniper (or whatever on top of
Tanker).

- Why Gin anyway?
Acronym of Next Gen Infobot (NGI).

- What's the flow structure?
You instantiate a new Tanker object with a path to a config file. I'm
not happy about this and plan to change it. It then loads the config
file actually it does nothing see above) and from that it works out what 
Plugins and RequestGenerators it needs to instantiate. It does that,    
passing them a reference to itself (this will probably change when I    
make everything extend a Generic Tanker Object [tm] which will provide  
Logging and Config methods). The Plugins it places in its Plugin array, 
the RGs it calls the run method. The RG then does whatever it wants to  
until everything is finished. Everytime the RG generates a Request it   
calls the inject method on the Tanker pipeline. Which then pumps it down 
a concurrent pipeline by looping through its Plugin array calling 

        $plugin->handle($request) 

on each one. The Plugin is free to munge the Request anyway it wants to.

- What happens after that? 
Theoretically ResponseHandlers will then look at it but I haven't 
decided on that bit yet.

- How does the concurrency work.
Everytime a new Request is generated, Tanker forks. This should work on 
most Perls except Macs because they're 74mE and can't preempt.

- Is any of this going to change?
Yes. Infact probably all of it will.


SHOWING YOUR APPRECIATION

There was a thread on the london.pm mailing list about working in a
vacumn - that it was a bit depressing to keep writing modules but never
get any feedback. So, if you use and like this module then please send
me an email and make my day. 

All it takes is a few little bytes.


COPYRIGHT

See COPYING