Bot-ChatBots

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

DESCRIPTION

    The Bot::ChatBots family of modules aim to help setting up ChatBots in
    different technologies.

    The basic model (still somehow in a state of flux) is an extension of
    Data::Tubes, with a few differences:

      * pipelines in Data::Tubes are usually assumed to know where to take
      their inputs and aim at processing all of it as fast as possible,
      while in this case the it generally comes asynchronously and over an
      indefinite length of time. This means that the sources of records are
      usually coded differently and then push records inside pipelines as
      they arrive;

      * processing in Data::Tubes is generally synchronous for simplicity,
      while in this case you might have longer running tasks. This can be
      addressed in different ways, one of which might be to split your
      pipeline into chunks, and decouple these chunks via some queuing
      mechanism.

    Apart from this, the suggested way to use Bot::ChatBots elements is
    sticking to the Data::Tubes way of work: define your pipelines, reuse
    already-available tube builders or code your own adhering to the
    (simple) tube interface.

lib/Bot/ChatBots.pod  view on Meta::CPAN

The basic model (still somehow in a state of flux) is an extension of
L<Data::Tubes>, with a few differences:

=over

=item *

pipelines in L<Data::Tubes> are usually assumed to know where to take
their inputs and aim at processing all of it as fast as possible, while in
this case the it generally comes asynchronously and over an indefinite
length of time. This means that the sources of records are usually coded
differently and then push records inside pipelines as they arrive;

=item *

processing in L<Data::Tubes> is generally synchronous for simplicity,
while in this case you might have longer running tasks. This can be
addressed in different ways, one of which might be to split your pipeline
into chunks, and decouple these chunks via some queuing mechanism.

=back

Apart from this, the suggested way to use Bot::ChatBots elements is
sticking to the L<Data::Tubes> way of work: define your pipelines, reuse
already-available tube builders or code your own adhering to the (simple)
tube interface.

lib/Bot/ChatBots/Role/Poller.pod  view on Meta::CPAN

=item *

L</poller> wraps a call to L</poll>, which is the real workhorse for
fetching data. The wrapping is such that L</poll> will not be called if
another instance of it is already running.

=item *

L</poll> - provided by your class - fetches new data and pushes this new
data to a callback. This allows asynchronous implementations, e.g. based
on L<Mojo::UserAgent> (which accepts a callback).

=item *

L</parse_response>, L</process_updates> and L</normalize_record> (required
by the base L<Bot::ChatBots::Role::Source>) are then called for
implementing the usual pipeline (parsing data into updates, process them
and normalize the resulting records).

=back

lib/Bot/ChatBots/Role/WebPoller.pod  view on Meta::CPAN

      tx_args => [qw< get http://example.com/whatever >],
      processor => \&process_record,
   );
   Mojo::IOLoop->start;

=head1 DESCRIPTION

This is a poller role for bots, polling from URLs. This role is actually
a derivation of L<Bot::ChatBots::Role::Poller>, adding a L</poll> method
that implements what needed for fetching data via HTTP/HTTPS
asynchronously.

You MUST provide C<tx_args> upon construction, pointing to an array
reference containing all parameters for fetching data. The contents of the
array is a list compatible with L<Mojo::UserAgent/build_tx>.

You can optionally configure a specific L<Mojo::UserAgent> as the C<ua>
parameter, e.g. if you want to set specific parameters like a timeout.

=head2 What Should You Provide/Override