Re: [infobot] infobot thoughts

[Rocco C. <rc...@po...>]

On Wed, Aug 04, 2004 at 12:57:15PM -0500, Tim Riker wrote:
> I heard from lenzo. I'll keep everyone informed as we chat.
> 
> Some thoughts on the way forward (in no particular order):
> 
> 1) infobot will stay in Perl. There are many other bot projects around 
> if folks want one in another language. see 
> http://supybot.sourceforge.net/ for one in python
> 
> 2) we need a new framework to better support tons of modules. Many of 
> the current and new modules should be forkers so that the base bot does 
> not get hung up.

Plugging my own code here:  I have a bot framework called workbench.
It consists of an IRC bot (you may have seen it on various networks
under the name "workbench") and a protocol for back-end services to
connect to it.  Services run in separate processes and can be on
different machines.

My notes are at http://poe.dyndns.org/~troc/bots/workbench.text
Code is in the same directory.

I haven't released it widely yet.  It doesn't have several amenities
that I think are vital for a production bot.  For example, it needs
process management to kill off and restart services.  It needs parsers
in the main bot process, so it doesn't have to multiplex messages to
every service every time.

The code's "same terms as Perl itself", though.  Feel free to borrow
ideas and bits of it.

> 3) I'd like to see sql backend instead of dbm. I'd prefer sqlite and 
> mysql, and any more that others want to add. sqlite allows for simple 
> file based access like dbm, but with the richer search capabilities.

You can effectively ignore the underlying database with a suitable
abstraction layer.  I think CPAN has a few already.  Class::DBI is one
I know by name.

> 4) I'd like to get as many of the infobot clones, and forks to join back 
> into the main tree. More eyes, more hands = more progress.

The bottom of http://poe.perl.org/?Projects_Using_POE lists several
IRC bots.  Some of them are infobot-alikes.  I wouldn't be surprised
if a lot of the links are out of date, though.

Two infobot forks/clones have come a long way:

http://sourceforge.net/projects/flooterbuck - Flooterbuck's the
infobot fork being developed by several irc.infobot.org (which is also
irc.perl.org) #perl regulars.  They're refactoring the code and
generally making it more maintainable.  One developer has made the
entire infobot into a workbench service.

http://sourceforge.net/projects/perl-fu - It's quite capable, and is
going into its third major revision.  It seems to have fallen off the
planet, though.  That's a shame.  It has some innovative features and
implements a decent subset of infobot.  Its author still appears
occasionally in EFNet #perlhelp, and he runs an instance there as the
local infobot-alike.

There's also a nascent repurl project being developed by the
Pound-Perl.PM people.  They can be found idling on #pound-perl.pm on
EFNet, irc.perl.org, Undernet, and OpenProjects.  If you can wake one
of them up, they might tell you where to find their development wiki.

> 5) I'd like to add email, web, and local admin interfaces at least. 
> email for things like CIA does now:
> 
> http://cia.navi.cx/stats/project/infobot
> 
> ie: posting cvs commits to a channel. web for basic factoid editing / 
> administration as well as new features like patchbot support:
> 
> http://sial.org/pbot/
> 
> and local interface for development and administration.
> 
> I have nothing against adding more protocols, but these are the main 
> ones I would like to see.

I've written a couple POE::Component::IRC bots that also have web
interfaces.

http://sourceforge.net/projects/memephage
http://sourceforge.net/projects/pastebot
http://sourceforge.net/projects/ircxom

Memephage and pastebot run embedded web servers.  Ircxom is an IRC to
Blosxom gateway, using the blog software as its web front end.  It
only publishes to the web; it doesn't take instructions from browsers.

To address a previous multi-protocol post, POE also has components for
AIM, Jabber, MSN, and Yahoo messenger.

> 6) I'd like to keep the run time memory and cpu footprint low. Use 
> forking, and a single select() call on the multiple interfaces would be 
> a Good Thing.
> 
> 7) I'd prefer that the code remain cross platform. Linux, *BSD, OSX, 
> *ix, and even (gag) win* should be supported. This likely means we avoid 
> perl threads etc. and stay multi-process.

I recommend POE::Component::IRC here.  It uses POE, which is select()
based and mostly Windows compatible.  One weak area is fork/exec,
which is emulated rather badly on Windows, but IPC::Run can be used to
spawn new processes.
http://search.cpan.org/~rbs/IPC-Run-0.78/lib/IPC/Run.pm#Win32_LIMITATIONS
has a good treatment of the issues.

> I setup a MediaWiki on SF, I don't yet have short URLs working and have 
> not skinned it etc, but we can start using it if folks want.
> 
> http://infobot.sourceforge.net/wiki/
> 
> Probably want to set it up to require registration to edit, but I have 
> not done that yet.

I recommend requiring registration once the URL spam starts up.
Registration requirements ended URL spam on a wiki I run.

> BZFlag maintainer - http://BZFlag.org/ - for fun!

My daughter loves BZFlag.  Thanks for maintaining it.

-- 
Rocco Caputo - http://poe.perl.org/