infobot-devel — Infobot use and development

Re: [infobot] Re: infobot mailing lists

[Kevin M. <pe...@pe...>]

On Wed, Aug 04, 2004 at 04:53:50PM +0100, David Cantrell (da...@ca...) pontificated:
> On Wed, Aug 04, 2004 at 05:14:13PM +0200, Jonathan Hitchcock wrote:
> 
> > Setting your withering sarcasm aside, I would have thought that the
> > benefits of the ability to sit on an IRC channel *and* be accessible via
> > MSN Messenger, Jabber, AIM, or SMS (via a GSM modem) is patently
> > obvious.
> 
> Not really.  I don't see the point of MSN Messenger, Jabber or AIM :-)
> and if I have GSM I can just ssh to my machine which is always running
> irssi.  Don't expect to see me putting any effort into supporting
> anything other than irc and email, cos that's all I care about for
> messaging.

Supporting various messaging protocols doesn't hurt. One good thing
about having a "smart" bot sitting on AIM/MSN/Jabber is that it could
be used to support clients.

Client AIM: What are your business hours?
BOT: We are open from 9-5 Eastern.
Client AIM: How do I install your product?
BOT: (spews install info)

Some of us spoke about this *way* back. 
 
> > An architecture that is not reliant on just one source is a good
> > architecture.
> 
> Abstraction for the sake of abstraction is a waste of time.  Why make
> people run two pieces of software (the backend and something to
> communicate between it and irc) when one is sufficient?  Or if you want
> to have an open specification with multiple monolithic implementations -
> why?  What a terrible waste of programmers' branes, all writing the same
> thing.  Wouldn't you rather write something innovative?

Maybe think of this in the same way DBI is done. DBI has all the nice
generic stuff, and you install the DBD::* driver module(s) you need. 

Infobot.pm
Infobot::Proto::IRC
Infobot::Proto::AIM
Infobot::Proto::Jabber
Infobot::Proto::MSN
Infobot::Proto::Email
etc...

> > That is not what I said at all.  Right from the beginning, I have simply
> > been suggesting some ideas and technologies which were not in the
> > original infobot.  I'm suggesting extending the original design and
> > embracing new methods.  I'm also clearly pissing people off by
> > suggesting that infobot is not perfect.
> 
> Don't be silly.  Infobot is a horrible mess.  But it's a horrible mess
> which WORKS, and it works NOW.  I'm happy to invest time and effort into
> making it less of a mess.  I'm not happy to waste time dicking around on
> some ludicrously over-engineered project which aims to be the be all and
> end all of bots but ends up with precisely 1 user (you) while everyone
> else sticks with what's far simpler to set up and which, let me say it
> again, WORKS NOW.
 
Sounds like we're done :-) 

Cheers,
Kevin

-- 
[Writing CGI Applications with Perl - http://perlcgi-book.com]
I was trying to daydream, but my mind kept wandering.
	-- Steven Wright

Re: [infobot] Re: infobot mailing lists

[Jonathan H. <vh...@ru...>]

> Don't be silly.  Infobot is a horrible mess.  But it's a horrible mess
> which WORKS, and it works NOW.  I'm happy to invest time and effort
> into making it less of a mess.  I'm not happy to waste time dicking
> around on some ludicrously over-engineered project which aims to be
> the be all and end all of bots but ends up with precisely 1 user (you)
> while everyone else sticks with what's far simpler to set up and
> which, let me say it again, WORKS NOW.

This is why I mentioned Knab in my first post.  It's written in perl,
not python.  It works, NOW.  It is used by hundreds of people, which is
completely unimpressive compared to most projects, but this one has
never even been officially released. This is just an indication that
it's not one fanatic sitting around talking to his own bot.  It is a
drop in replacement for infobot - it uses infobot's databases, if you
want, it has all the functionality of infobot, it even looks like an
infobot.
And, most importantly, it's NOT a horrible monolithic mess.  Which is
not to say it's perfect.  It's not.  But it's got some ideas which could
be used when you start designing the new infobot.  That's all.

Meta-discussion vs. details

[Joe M. <mc...@ib...>]

The disagreement here seems to be one of scope.

I think Jonathan is bringing up the question of "Are we approaching the 
problem in the best possible way here?" instead of saying "I want to 
throw out the Perl code and switch to Python". That is definitely *not* 
what I'm hearing here.

Establishing an agreed-upon framework for implementing bots and/or a 
protocol for communicating between bots doesn't seem like a bad idea to 
me. A given implementation can decide whether or not to participate in 
the protocol or not. One could consider extending the protocol so that 
a given bot presence could actually be made up of a network of 
interacting source and sink bots, with a central server/network of 
server bots, for instance. Doesn't it suck when purl drops off #perl? 
Wouldn't it be nice if there could be a silent switchover to a second 
(or third, or ...) purl while the primary is down? Wouldn't it be nice 
to be able to share a database with someone else, if you wanted to?

I admit that possibly this is overengineering. I don't think there's a 
compelling reason to switch languages, either, but there *might* be 
some gain from coming up with a networking implementation. IRC works 
because there's an agreed-upon protocol for the servers to "relay" the 
chat traffic. A little thought on what to accomplish is time well 
spent.

I remember Andy Lester's talk in which he quoted Nat Torkington: 
"...it's hard to find capable, intelligent volunteers[;] chas[ing] one 
away [is] a reprehensible act of destruction." Let's not do that.

I think that discussing the possibilities of an architecture would be a 
useful thread here; there's nothing that says the infobot project can't 
release multiple implementations in different languages; that's a 
matter of handling distributions. Sourceforge does tend to put one in 
the "one product per project" box; maybe we ought to consider whether 
we can do something to fix that.

  --- Joe M.

Re: [infobot] Re: infobot mailing lists

[David C. <da...@ca...>]

On Wed, Aug 04, 2004 at 05:14:13PM +0200, Jonathan Hitchcock wrote:

> Setting your withering sarcasm aside, I would have thought that the
> benefits of the ability to sit on an IRC channel *and* be accessible via
> MSN Messenger, Jabber, AIM, or SMS (via a GSM modem) is patently
> obvious.

Not really.  I don't see the point of MSN Messenger, Jabber or AIM :-)
and if I have GSM I can just ssh to my machine which is always running
irssi.  Don't expect to see me putting any effort into supporting
anything other than irc and email, cos that's all I care about for
messaging.

> An architecture that is not reliant on just one source is a good
> architecture.

Abstraction for the sake of abstraction is a waste of time.  Why make
people run two pieces of software (the backend and something to
communicate between it and irc) when one is sufficient?  Or if you want
to have an open specification with multiple monolithic implementations -
why?  What a terrible waste of programmers' branes, all writing the same
thing.  Wouldn't you rather write something innovative?

>               Abstraction from the nitty-gritty of protocol is a good
> thing.  That's all I was saying.

Every time I've hacked on infobot I didn't need to go anywhere need the
nitty-gritty of the irc protocol.

> That is not what I said at all.  Right from the beginning, I have simply
> been suggesting some ideas and technologies which were not in the
> original infobot.  I'm suggesting extending the original design and
> embracing new methods.  I'm also clearly pissing people off by
> suggesting that infobot is not perfect.

Don't be silly.  Infobot is a horrible mess.  But it's a horrible mess
which WORKS, and it works NOW.  I'm happy to invest time and effort into
making it less of a mess.  I'm not happy to waste time dicking around on
some ludicrously over-engineered project which aims to be the be all and
end all of bots but ends up with precisely 1 user (you) while everyone
else sticks with what's far simpler to set up and which, let me say it
again, WORKS NOW.

-- 
David Cantrell | Reality Engineer, Ministry of Information

      Good advice is always certain to be ignored,
      but that's no reason not to give it            -- Agatha Christie

Re: [infobot] Re: infobot mailing lists

[Rob P. <rj...@fr...>]

> Setting your withering sarcasm aside, I would have thought that the
> benefits of the ability to sit on an IRC channel *and* be accessible via
> MSN Messenger, Jabber, AIM, or SMS (via a GSM modem) is patently
> obvious.

I have a scribot that's accessible via IRC, Jabber, HTTP, and Spread.  It
is, indeed, a lot handier than having the bot sitting on just IRC. 

In a worryingly geeky way, I suppose, since I can submit URLs via the 
Jabber client on my phone.  Hmm.  Maybe I need to get out more.

Re: infobot mailing lists

[Jonathan H. <vha...@ru...>]

*sigh*

> Perl is a perfectl tool for the job.  There may be others equally
> suitable, but that is not an adequate reason for using them.

If there were others *more* suitable, however, that would be an adequate
reason for using them.  That's all I was saying.  I wasn't even
suggesting a language, I was suggesting that people think about it.

I'm sorry for treading on perl's toes, I shall not mention it again.  I
merely thought that infobot developers would be more keen on discussing
the best method for making a bot than sticking to the norms and
conventions laid down by infobot ages ago

> Somebody has already done a lot of re-implementation in perl.

Yes.  Me.

> Well yeah, I can see a real need for that.  I'm running a bot that's
> sitting on an IRC channel I use and rather than talk to the bot on the
> IRC channel I would much prefer to fire up a Java crapplet and talk to
> it directly.  Oh, I see what you're getting at.  I could run the bot
> without it talking to anyone but me via my desktop and I could teach it
> things and then later I could ask it about stuff I already know.

Setting your withering sarcasm aside, I would have thought that the
benefits of the ability to sit on an IRC channel *and* be accessible via
MSN Messenger, Jabber, AIM, or SMS (via a GSM modem) is patently
obvious.

An architecture that is not reliant on just one source is a good
architecture.  Abstraction from the nitty-gritty of protocol is a good
thing.  That's all I was saying.


> >Even the original infobot source has a method that allows two bots to
> >share their data.
> 
> IF you wanted it to.  In some situations that might be desirable, in
> others it most definitely is not.

That much is trivially obvious.  All behaviour should be configurable,
as a matter of course.

> OK, you've convinced me.  Let's rip out the IRC support and Yahoo
> support and create our own message service based on PB.

That is not what I said at all.  Right from the beginning, I have simply
been suggesting some ideas and technologies which were not in the
original infobot.  I'm suggesting extending the original design and
embracing new methods.  I'm also clearly pissing people off by
suggesting that infobot is not perfect.

> Then we persuade all the IRC users to switch just so they can talk to
> our wonderful bots.

Please.  There was absolutely no call to get so sarcastic and snide.  I
never suggested any of these.

> The only reason for needing another protocol so that bots can communicate
> is if they're on different servers.

That's the only bloody reason I suggested it in the first place.
Different bots on different servers can still communicate SHOULD THEY
WANT TO.


Look, forget it.  Go ahead.  I'll sit in the background until you start
developing.

Re: infobot mailing lists

[Paul L. A. <pl...@so...>]

Jonathan Hitchcock writes: 

> All I was saying is that a fresh look at everything, the pros and cons
> of python/perl/everything else should be examined, and the right tool
> chosen for the job.

Perl is a perfectl tool for the job.  There may be others equally
suitable, but that is not an adequate reason for using them.  Somebody
has already done a lot of re-implementation in perl.  If he were
more comfortable with Python he'd have done it in that, so it's unlikely
he will want to switch to Python just because you prefer it.  If you want
to write your own bot in Python then go right ahead. 

>> Again, it seems silly to bring another communications protocol into
>> play if you want to do this, since the whole purpose of the bots is to
>> be on IRC.
> 
> I'd say the whole purpose of a bot is to be available for queries.
> Whether those queries come from IRC, Jabber, AIM, or a desktop applet,
> a well designed bot should still be able to respond to them.

Well yeah, I can see a real need for that.  I'm running a bot that's
sitting on an IRC channel I use and rather than talk to the bot on the
IRC channel I would much prefer to fire up a Java crapplet and talk to
it directly.  Oh, I see what you're getting at.  I could run the bot
without it talking to anyone but me via my desktop and I could teach it
things and then later I could ask it about stuff I already know. 

>> Not that I would ever want a bot I run getting orders from a bot
>> somebody else runs.
> 
> Even the original infobot source has a method that allows two bots to
> share their data.

IF you wanted it to.  In some situations that might be desirable, in
others it most definitely is not.  You've also incidentally shot down
any reason for using some external protocol to share data because the
bots can already do that. 

> When I mentioned Python, I mentioned it because it was a good language
> for the task (including its platform independence).  When I mentioned
> Perspective Broker, I mentioned it because it is a nice efficient way
> for applications to communicate remotely IF THEY SHOULD WANT TO.

OK, you've convinced me.  Let's rip out the IRC support and Yahoo
support and create our own message service based on PB.  Then we
persuade all the IRC users to switch just so they can talk to our
wonderful bots.  That way we wouldn't have any unnecesary protocols where
we use one protocol to talk to the bots and a different one for bots to
talk to each other.  Or maybe after we switch everyone to chatting by
PB we could put the IRC handler back in so that the bots can talk to
each other by a completely different protocol for no good reason. 

The only reason for needing another protocol so that bots can communicate
is if they're on different servers.  However, in that situation the new
Yahoo support could be used for intercommunication.  Alternatively, and
better, would be an enhancement to allow a bot to be on more than one
server. 

-- 
Paul Allen
Softflare Support 

Re: infobot mailing lists

[Paul L. A. <pl...@so...>]

David Cantrell writes: 

>> > One way NOT to go is C# or any other single-platform language/language
>> > variant.  So that pretty much limits you to Perl, Java, C and C++.
> 
> C# was multi-platform, I thought, if you use mono.

Until Microsoft decide that there is enough application code written in C#
running on those other platforms that they will stop supporting it in order
to force people to switch to Windows.  It's how they operate. 

-- 
Paul Allen
Softflare Support 

Re: [infobot] Re: infobot mailing lists

[David C. <da...@ca...>]

On Wed, Aug 04, 2004 at 02:37:30PM +0200, Jonathan Hitchcock wrote:
> > >Is Perl the way the bot should go?  Is it the best choice?  Why?

I'd say yes, and yes.  As for why - well, it's already written in perl,
and I expect that most people who have hacked on it are familiar with
perl, more than they are with (eg) Java or Python.

If you want to write a *new* bot, then by all means use some other
language, but it will be new project and a new bot.  I will also most
likely not be interested.  Partly because I'm most familiar with perl,
partly because I have no other need to install java or python and I
won't install them for something as trivial as an IRC bot.  I pay for my
disk space, and have an uncomfortably small amount of free space, but I
need perl for other stuff anyway.

> > >specific choice of language a good way to go?  In today's multi-lingua
> > >world, should we stick to one language, or have a source-independent
> > >API, communicating with RPC or PB or SOAP?

Ugh.  That reeks of suit-inspired over-engineering.

> > One way NOT to go is C# or any other single-platform language/language
> > variant.  So that pretty much limits you to Perl, Java, C and C++.

C# was multi-platform, I thought, if you use mono.  I even hear that
it's quite a nice language.

> I was heading towards Python with my question ;-)
> 
> Python is platform independent, wonderfully structured, easy to code in,
> and has lots of beautiful modules that make stuff easy.

All of that applies to perl.  Well, maybe not the wonderfully
structured.  I've not looked at the sources for python so have no idea
how wonderful its guts are.  But it's easy to write portable, well
structured code in perl, and unlike python, perl has CPAN.

> And Python/Twisted (http://www.twistedmatrix.com/) makes programming
> network applications ridiculously simple.

As do POE, SOAP, and the socket stuff in perl.

> Again, Perspective Broker has all the advantages and none of the
> disadvantages.

I don't believe that for one moment.

>                I just think it might be useful for different bots to
> communicate with each other ...

Bots can already communicate with each other, in private messages.
Infobots do it.

-- 
David Cantrell | Official London Perl Mongers Bad Influence

  God not only plays with dice, he sometimes
  throws them where they can't be seen
     -- Stephen Hawking

Re: infobot mailing lists

[Jonathan H. <vha...@ru...>]

> Ummm, platform independence?  Can you get Python for windows? 

Of course!
http://www.python.org/download/download_windows.html

All I was saying is that a fresh look at everything, the pros and cons
of python/perl/everything else should be examined, and the right tool
chosen for the job.

> Again, it seems silly to bring another communications protocol into
> play if you want to do this, since the whole purpose of the bots is to
> be on IRC.

I'd say the whole purpose of a bot is to be available for queries.
Whether those queries come from IRC, Jabber, AIM, or a desktop applet,
a well designed bot should still be able to respond to them.

> Not that I would ever want a bot I run getting orders from a bot
> somebody else runs.

Even the original infobot source has a method that allows two bots to
share their data.  If I ask my bot something that it doesn't know, it
will ask all "friendly" bots I have told it about, and if one of them
has an answer, my bot will learn from it.  This is a wonderful feature,
and should never be dismissed by describing it as "getting orders from
somebody else's bot".

> I'm surprised you didn't mention Corba and XML.

I didn't mention them because they're slow, inefficient, bloated, messy,
and complicated.

Give me some credit.

When I mentioned Python, I mentioned it because it was a good language
for the task (including its platform independence).  When I mentioned
Perspective Broker, I mentioned it because it is a nice efficient way
for applications to communicate remotely IF THEY SHOULD WANT TO.

> Sorry if I sound cynical, but I've seen the results of misapplying
> stuff like that.

As have I.  As I said, give me some credit.


Back to my original point:  Let's not assume that any way is the best
architecture just yet.  Let's have a look at the options, and design a
bot that will work properly, from scratch.

Re: infobot mailing lists

[Paul L. A. <pl...@so...>]

Jonathan Hitchcock writes: 

> I was heading towards Python with my question ;-)

Ummm, platform independence?  Can you get Python for windows? 

> Again, Perspective Broker has all the advantages and none of the
> disadvantages.  I just think it might be useful for different bots to
> communicate with each other and share modules.  But that's waaaay in the
> future.

Again, it seems silly to bring another communications protocol into play
if you want to do this, since the whole purpose of the bots is to be
on IRC.  You already have a communications layer there.  Not that I would
ever want a bot I run getting orders from a bot somebody else runs.  But
if I did it would make more sense to layer something on top of what is
already there. 

I'm surprised you didn't mention Corba and XML.  Everybody who wants to
design bloatware drags those two monsters into things.  "What can I do
to make this slow, inefficient and make the messages far less
comprehensible and much harder to debug?  I know!  Corba and XML!  If
I fiddle with the DTD enough I can make it so you need 1MB of XML garbage
just to send a smiley." 

Sorry if I sound cynical, but I've seen the results of misapplying stuff
like that.  Whatever happened to simplicity and elegance in design?  What
happend to the Unix programming philosophy of keeping tools and
protocols small and simple?  Why do people insist on introducing
unnecessary complications? 

-- 
Paul Allen
Softflare Support 

Re: infobot mailing lists

[Jonathan H. <vha...@ru...>]

> >Is Perl the way the bot should go?  Is it the best choice?  Why?  Is
> >specific choice of language a good way to go?  In today's multi-lingua
> >world, should we stick to one language, or have a source-independent
> >API, communicating with RPC or PB or SOAP?
> 
> One way NOT to go is C# or any other single-platform language/language
> variant.  So that pretty much limits you to Perl, Java, C and C++.

I was heading towards Python with my question ;-)

Python is platform independent, wonderfully structured, easy to code in,
and has lots of beautiful modules that make stuff easy.

And Python/Twisted (http://www.twistedmatrix.com/) makes programming
network applications ridiculously simple.
See:
  http://www.twistedmatrix.com/documents/current/howto/clients

Just a thought.

> As for RPC, PB and SOAP, those are more of a hindrance than an advantage.

Again, Perspective Broker has all the advantages and none of the
disadvantages.  I just think it might be useful for different bots to
communicate with each other and share modules.  But that's waaaay in the
future.

Baby steps, right?

Re: infobot mailing lists

[Paul L. A. <pl...@so...>]

Jonathan Hitchcock writes: 

> Is Perl the way the bot should go?  Is it the best choice?  Why?  Is
> specific choice of language a good way to go?  In today's multi-lingua
> world, should we stick to one language, or have a source-independent
> API, communicating with RPC or PB or SOAP?

One way NOT to go is C# or any other single-platform language/language
variant.  So that pretty much limits you to Perl, Java, C and C++.  All
of them have regular expression add-ons, but only Perl integrates
regexes as smoothly. 

As for RPC, PB and SOAP, those are more of a hindrance than an advantage.
Especially in this instance where the bot is running on a single computer
and communicates via IRC.  There is absolutely no need to drag those into
it and every reason not to because of bloat and security issues. 

-- 
Paul Allen
Softflare Support 

Re: [infobot] infobot mailing lists

[<ho...@mi...>]

On Tue, 3 Aug 2004, Tim Riker wrote:

> As for the mailing lists... I guess I don't care much one way or the 
> other.  I would like a cvs commits list, and SF already offered list 
> archiving etc. so I went that direction as the path of least resistance. 
> Do you run the current list or just archive it?
> 
> If you don't who does run the current list? metronomicon.com is another 
> of kevin's domains, so I presume it would be kevin himself.

Yes I assume a mail server's ticking away quietly at wherever Kevin
hosts it.  I just subscribe a list archive address to his list, which
receives the mails and does the archiving and indexing on my site, so
no, I don't have any control over the list itself.  From memory, his
archive was incomplete so I offered, and he said yes.

> Oh, and thanx for running the searchable list! I've used it many times.
> 
> Do you have a preference? ie: would you like to still host the 
> searchable lists or would you rather we just use SF? SF does archiving 
> but no real searching. Having the search feature is nice.

I don't really have a preference no. SF's lack of easy searchability's
always a problem, but if you want to keep it clean and to the
sf.net standard you could go with that.  Or I don't mind keep
mine up and running it in parallel if you like.  Up to all of you.
All I'd need is a clean break to know which list is the master list
- with two running right now and already (I've noticed, I think),
one mail being sent to the SF one but not here, it's getting messy.
And I can't archive both or I'll get duplicates.

I don't really have time right now to mess with the archiving format
on my site, but if people think it's useful as it is, and someone can
send a clear signal as to when to make a change, just let me know.
Else I'll leave the old one subscribed and the archive will rot :)

Re: [infobot] infobot mailing lists

[Jonathan H. <vha...@ru...>]

> Everyone I've talked to agrees that infobot is dead in it's current 
> form. There are a ton of forks with new names and most of them have 
> implemented the same types fo features, but differently.
> 
> My hope would be to get some of the forks back working on the same set 
> of sources. More eyes/hands equals faster progress.
> 
> I'd like to come to some consensus as to a new design first. If that's 
> not possible than the forks will continue.

How about a wiki and an IRC channel, and some active interest, and
thoughts on how a 'bot' should work?

Having worked on Knab for all this time, I have big ideas on "What A Bot
Should Be" (most of which are along the lines of "Exactly Unlike What I
Did When I Implemented Such And Such", experience has such a way of
teaching you how NOT to do stuff).  I'd love to get involved from
scratch again.

Is Perl the way the bot should go?  Is it the best choice?  Why?  Is
specific choice of language a good way to go?  In today's multi-lingua
world, should we stick to one language, or have a source-independent
API, communicating with RPC or PB or SOAP?


The fantastic thing about infobot is that anybody who was ever
interested in bots has looked at an infobot at some stage or other.
That's a large resource to draw on.  Count me in, anyway.


(At least lets get a freenode IRC channel started?)

Cheers,
-Jonathan

Re: [infobot] infobot mailing lists

[Tim R. <Ti...@Ri...>]

I've tried to contact Kevin a number of times and gotten no reply. I was 
hoping he'd be on the Perl Whirl cruise this year, but I did not see him 
on the list.

Everyone I've talked to agrees that infobot is dead in it's current 
form. There are a ton of forks with new names and most of them have 
implemented the same types fo features, but differently.

My hope would be to get some of the forks back working on the same set 
of sources. More eyes/hands equals faster progress.

I'd like to come to some consensus as to a new design first. If that's 
not possible than the forks will continue.

I am currently using blootbot mostly because I got sick of maintaining 
my own patches to infobot and nobody on the project was responding at 
the time.

As for the mailing lists... I guess I don't care much one way or the 
other.  I would like a cvs commits list, and SF already offered list 
archiving etc. so I went that direction as the path of least resistance. 
Do you run the current list or just archive it?

If you don't who does run the current list? metronomicon.com is another 
of kevin's domains, so I presume it would be kevin himself.

Anyone close to Pittsburg that can ping Kevin?

Oh, and thanx for running the searchable list! I've used it many times.

Do you have a preference? ie: would you like to still host the 
searchable lists or would you rather we just use SF? SF does archiving 
but no real searching. Having the search feature is nice.

ho...@mi... wrote:
> I've been running a searchable mailing list archive for the infobot
> list for some time on request way back in (I think) 1999, still linked
> from the Infobot site, at:
> 
> http://www.missprint.org/infobot/
> 
> What would you all like me to do with this?  Subscribe the new list
> to it and continue archiving, or leave it?
> 
> Has anyone had any contact with Kevin Lenzo over this?  Tim, have you
> tried to contact him at http://www.cepstral.com or other addresses
> via Google?  If the (seemingly dead) project is being forked without
> successful contact with the owner, should it have a new name?


-- 
Tim Riker - http://rikers.org/ - Ti...@De...
Linux Technologist - Ti...@TI... - http://www.TI.com/
BZFlag maintainer - http://BZFlag.org/ - for fun!

Re: [infobot] infobot mailing lists

[Tim R. <Ti...@Ri...>]

Ideally I'd like to point infobot.org and www.infobot.org over to SF 
instead of the box they are on now.

I pulled down what I could using wget. It's now on SF in the 
infobot/htdocs directory. It looks like there are some cgi-bin/* scripts 
on infobot.org too. It would be nice to get them copied over. You have 
shell access to the SF site too, so perhaps you can compare the two?

Note that I converted any hardcoded "http://www.infobot.org/" links to 
relative links so they would work on SF.

http://infobot.sourceforge.net/

I'll probably check all the old versions in the SF downloads area and 
remove them from the web tree.

I'm working on setting up a wiki at the moment, and once up I'll likely 
convert most of the site into wiki pages for easier updating.

Looks like there are some symlinks on infobot.org like:

/snapshots/factpacks -> /factpacks
/factpacks/snapshots -> /snapshots

correct? There may be more with the -current tarball images etc.

Kevin Meltzer wrote:
> On Tue, Aug 03, 2004 at 01:51:58PM -0500, Tim Riker (Ti...@ri...) pontificated:
> 
>>Does anyone have shell access to the infobot.org server? I've copied 
> 
> 
> I do. Whatcha need?
> 
> Cheers,
> Kevin
> 


-- 
Tim Riker - http://rikers.org/ - Ti...@De...
Linux Technologist - Ti...@TI... - http://www.TI.com/
BZFlag maintainer - http://BZFlag.org/ - for fun!

Re: [infobot] infobot mailing lists

[<ho...@mi...>]

On Tue, 3 Aug 2004, Tim Riker wrote:

> I'd like to move over to the sf mailing list 
> (inf...@li...) soon. I don't have access to the 
> other list server and I don't know anyone that does.
> 
> Does anyone have shell access to the infobot.org server? I've copied 
> over the static pages to SF so that:
> 
> http://infobot.sourceforge.net/
> 
> looks like:
> 
> http://infobot.org/

I've been running a searchable mailing list archive for the infobot
list for some time on request way back in (I think) 1999, still linked
from the Infobot site, at:

http://www.missprint.org/infobot/

What would you all like me to do with this?  Subscribe the new list
to it and continue archiving, or leave it?

Has anyone had any contact with Kevin Lenzo over this?  Tim, have you
tried to contact him at http://www.cepstral.com or other addresses
via Google?  If the (seemingly dead) project is being forked without
successful contact with the owner, should it have a new name?

Re: [infobot] infobot mailing lists

[Kevin M. <pe...@pe...>]

On Tue, Aug 03, 2004 at 01:51:58PM -0500, Tim Riker (Ti...@ri...) pontificated:
> 
> Does anyone have shell access to the infobot.org server? I've copied 

I do. Whatcha need?

Cheers,
Kevin

-- 
[Writing CGI Applications with Perl - http://perlcgi-book.com]
Share the groove.
	-- Phish (Weekapaug Groove)

infobot mailing lists

[Tim R. <Ti...@Ri...>]

I'd like to move over to the sf mailing list 
(inf...@li...) soon. I don't have access to the 
other list server and I don't know anyone that does.

Does anyone have shell access to the infobot.org server? I've copied 
over the static pages to SF so that:

http://infobot.sourceforge.net/

looks like:

http://infobot.org/

And I'm planning to setup a wiki there that we can use to track projects 
related to infobot as well as hash out the desired feature set of a new 
infobot release.

The blootbot project has many of the features discussed here. Per 
channel configuration, cronjob like scheduler, mysql/sqlite backend, 
configurable speak-when-spoken-to and addressCharacter.

I never fixed the insult module, but google, exchange, convert, botmail 
and many others are working fine.

I have it setup to handle multiple connections as different nicks, but 
it's kind of a hack at present.

I'll email the SF list with more comments...

Signup here:

http://sourceforge.net/mail/?group_id=2241

Archives here:

http://sourceforge.net/mailarchive/forum.php?forum_id=41542
-- 
Tim Riker - http://rikers.org/ - Ti...@De...
Linux Technologist - Ti...@TI... - http://www.TI.com/
BZFlag maintainer - http://BZFlag.org/ - for fun!

Re: Infobot rebirth?

[Paul L. A. <pl...@so...>]

Jonathan Hitchcock writes: 

> Sorry, I should have made it clear.  It's not obstinacy on my part - the
> bot is configurable to do everything you said.

That's good. 

> In this way, and with the right setting of priorities, you can order
> your modules to respond to pretty much any sort of IRC situation.  The
> only thing you cannot do is have the bot suddenly pipe up out of
> nowhere.

Ummm, there are times when it is useful for the bot to react to events
which are not technically somebody speaking.  In particular, in some
situations it may be desirable for a bot to send a public or private
(configurable) message when somebody joins the channel.  That person
didn't "say" anything but there was channel activity. 

> I have implemented this, I forgot to demonstrate it, sorry ;-)

That's OK. :) 

> I actually made an inline version of the insult server:

It's what I did too.  Made sense to run it from the command line. 

> I never got the excuses module working in the old infobot,

I think it used to work, but I can't remember for sure.  I know I set
up an infobot for somebody a few months ago and ended up rewriting the
excuses module for some reason.  I can't remember if it was because I was
annoyed at the inefficiency of the original or because it wouldn't work. 

> Knab, of course, uses perl's sorry attempt at object-oriented
> programming,

Perl's OOP is actually an elegant kluge.  However, I dislike OOP so I
try to avoid using it. 

> You see why the modular, hot-pluggable, local-namespace,
> per-module-configuration approach is easier to code than infobot's
> monolithic "shove everything into one big loop" way of doing things?

Obviously, even if you did it using OOP.  I don't blame the original
author though, because infobot evolved from very humble beginnings and
so things got tacked on.  A re-implementation made a lot of sense. 

I'd be tempted to amalgamate excuse and zippy into a generic module.
Have the config file specify that the response to "excuse" is to call
the random_quote (for want of a better name) routines using the file
excuse.txt (or whatever you want to call it).  Easy enough to do with
OOP (and just as easy to do without if you're familiar with Perl).  Data
files would only get loaded when the relevant command is given for the
first time.  Optional extra: store the timestamp when the file was loaded
and sny time the command is given reload if the mtime on the file is more
recent. 

BTW, I'd have used aspell/ispell (on many systems ispell is actually
a compatibility wrapper around aspell, so if you code for ispell you
have both covered) for checking spelling. 

Hmmm, while I think about it...  It would be nice to have per-channel
configurability, inheriting from a default configuration unless
over-ridden.  Sometimes different channels require different configurations
and/or different sets of factoids.  But you've probably already done that
because you seem to have done most of the things that I hacked into the
original. 

-- 
Paul Allen
Softflare Support 

Re: Infobot rebirth?

[Jonathan H. <vha...@ru...>]

> This is not always desirable.  In some situations you want the bot to
> respond to anything that looks like a question (like a support channel
> which is not monitored continuously) or to respond to words (or actions,
> a feature missing from the original, as I recall). 

The "speak when spoken to" thing is more the way I feel a well-designed
bot should behave, otherwise it's irritating.  I mentioned the rule
merely to illustrate the architecture, actually.  It precludes things
like a cronbot ("every ten minutes, tell me to check my laundry",
something which is useful, and which I've coded up in Python/Twisted),
because the processing and replying only gets done when the Source
receives input to trigger it off.

With Knab, there is a per-module configuration option called
"addressed", which specifies whether the bot needs to be directly
addressed for the module to receive the input.  For example, the "See"
module needs to receive all input, regardless of whether it is addressed
to the bot or not, because it needs to keep track of everything
everybody said (for "bot: seen Vhata?").  The point is, however, that
something still needs to actually BE SAID for the bot to react - it
can't suddenly do something out of the blue.

(There is an example module which causes the bot to say "Hooray!" every
time anybody mentions the word "boobies" in any context, which
illustrates this... ;-)

> The things should be configurable, not hardwired one way simply
> because of the way you want it to operate.  That's good design.  It
> also reduces the chance of somebody forking the project because you
> refuse to add stuff they want. 

Sorry, I should have made it clear.  It's not obstinacy on my part - the
bot is configurable to do everything you said.  Each module can be given
the following configuration options:

addressed = true     ; means the module will only process queries
                     ; directed to the bot
public = true  ; means the module only processes public queries (e.g.
               ; for karma)
postprocessor = true  ; means the module will even receive queries that
                      ; another module has marked as "processed" (e.g.
                      ; for a module that rot13s all output)

In this way, and with the right setting of priorities, you can order
your modules to respond to pretty much any sort of IRC situation.  The
only thing you cannot do is have the bot suddenly pipe up out of
nowhere.


> ><Vhata> Spinach: foo is also bing
> [...]
> ><Spinach> foo =has= nothing on bar; and =is= bar|bing
> 
> There are times when you want "also" to give bar|bing and times when you
> want it to behave as the original with "foo is bar and also bing."  I
> hacked the original so that a different keyword gave the | behaviour.  I'd
> suggest "alternatively." 

I have implemented this, I forgot to demonstrate it, sorry ;-)

<Vhata> Spinach: foo is bar
<Spinach> Vhata: okay
<Vhata> Spinach: foo += ry manilou
<Spinach> Vhata: sure thing
<Vhata> Spinach: foo?
<Spinach> foo is barry manilou

The "=~ s/search/replace/" syntax also works, although I have
implemented it so that you can use s///g to do ALL
search-and-replacements, and use s///r to use real perl regular
expressions to search and replace.

If there is more than one alternative for a factoid that matches the
search term, you need to specify which one you are working on, unless
you gave the 'g' flag, of course, in which case it works on all of them:

<Vhata> Spinach: foo is bar
<Spinach> Vhata: okay
<Vhata> Spinach: foo is also baz
<Spinach> Vhata: gotcha
<Vhata> Spinach: foo =~ s/b/x/
<Spinach> Vhata: Factoid has too many alternatives that match, I
          don't know which to alter!
<Vhata> Spinach: foo /z/ =~ s/b/x/
<Spinach> Vhata: okay
<Vhata> Spinach: foo =~ s/a/v/g
<Spinach> Vhata: gotcha
<Vhata> Spinach: literal foo
<Spinach> foo =is= xvz|bvr


> People enjoyed the insult server.  It's no longer running, but the sources
> are still available, and it's a simple matter then to run it from the
> command line.  Spell checking is also good

I actually made an inline version of the insult server:

<Vhata> Spinach: insult NSync
<Spinach> NSync, thou weedy, ill-breeding mammet
<Vhata> Spinach: insult me
<Spinach> Vhata, thou loggerheaded, hell-hated giglet
<Vhata> Spinach: insult yourself
<Spinach> Vhata is nothing but a puking half-mouthful of off-color
          cat hair.

This uses data stored locally, and doesn't need to contact a server
running somewhere else (or even running locally).

Spell checking is done using the Dict module, which contacts a
dict.org dictionary server.

> You can also speed up the excuses module a lot

I never got the excuses module working in the old infobot, and never
tried to get it working in Knab.  But Knab is a rewrite from scratch
using ideas from infobot - you can't just import infobot code, you need
to make perl modules which conform to the Knab API...

> IIRC, there are other modules that pollute global namespace in order
> to have static data which would be better off if converted to use
> private data.

Knab, of course, uses perl's sorry attempt at object-oriented
programming, so each module keeps its data in the local namespace, so
this isn't a problem.  The only global variables are $::dumper and
$::conf, which are used by all modules to access the data dumper and the
configuration file.  ;-)

> Or maybe you've already done that in your rewrite.  If so, I'll teach
> you how to suck eggs instead. :) 

I'm always willing to learn new skills  ;-)


Here's some skeleton code for a Knab module that responds to queries
that look like "XXXX [number]", and returns that number-plus-one.

sub Match {
	my $this = shift;
	my $match = pop @_;
	my (%query) = @_;
	return undef if($query{input} !~ m/^\s*XXXX\s+(\d+)\s*$/i);
	return 1 if($match);
	return ($1);
}

sub Process {
	my $this = shift;
	my (%query) = (@_);
	
	my ($num) = $this->Match(%query,0);
	push @{$query{responses}}, { 
	            action => 0, 
					target => $where, 
					reply => $query{who}.": ".($num+1) 
	         };
	$query{processed} = 1;
	return %query;
}


Match() is called from the Processor with the query hash and the second
argument set to true.  If this second argument is true, then Match()
only needs to return true or false, to say whether this module is
"interested" in that query or not.  Later on, you see, in the Process()
function (which gets called if the module *is* interested in the query),
Match() gets called again, and passed a false second argument.  This
means that it must return an array containing the relevant "bits" of the
query.  So, if the query were "exchange 10 USD into GBP", the array
would contain [ 10, "USD", "GBP" ], easily accessible by the Process()
function without the need for more fancy regex.


This structure can be used to code up whatever query-response module you
want, and shoved into the Knab's modules directory, and then the bot can
be told to load that module (even if the bot is currently running at the
time), and away it goes.


You see why the modular, hot-pluggable, local-namespace,
per-module-configuration approach is easier to code than infobot's
monolithic "shove everything into one big loop" way of doing things?


Thanks for the input,
Cheers,
-Jonathan

Re: Infobot rebirth?

[Paul L. A. <pl...@so...>]

Jonathan Hitchcock writes: 

> There is a certain article of faith of mine: 
> 
> <Vhata> Spinach: rule #1 for bots
> <Spinach> rule #1 for bots is Speak Only When Spoken To

This is not always desirable.  In some situations you want the bot to
respond to anything that looks like a question (like a support channel
which is not monitored continuously) or to respond to words (or actions,
a feature missing from the original, as I recall). 

The things should be configurable, not hardwired one way simply because
of the way you want it to operate.  That's good design.  It also reduces
the chance of somebody forking the project because you refuse to add
stuff they want. 

> <Spinach> foo =is= baz
> <Vhata> Spinach: forget foo
[...]
> <Vhata> Spinach: foo is also bing
[...]
> <Spinach> foo =has= nothing on bar; and =is= bar|bing

There are times when you want "also" to give bar|bing and times when you
want it to behave as the original with "foo is bar and also bing."  I
hacked the original so that a different keyword gave the | behaviour.  I'd
suggest "alternatively." 

People enjoyed the insult server.  It's no longer running, but the sources
are still available, and it's a simple matter then to run it from the
command line.  Spell checking is also good. 

You can also speed up the excuses module a lot (at the expense of some
memory.  Wrap the subroutine in braces, declare a my(@excuses) array
before the subroutine definition so it's static but private (doesn't
pollute global namespace), inside the subroutine itself load the array
from the excuses file unless @excuses is true, then calculate a random
array index based on the size of @excuses and return the appropriate line. 

IIRC, there are other modules that pollute global namespace in order
to have static data which would be better off if converted to use
private data.  Or maybe you've already done that in your rewrite.  If so,
I'll teach you how to suck eggs instead. :) 


-- 
Paul Allen
Softflare Support 

Re: [infobot] Infobot rebirth?

[Jonathan H. <vha...@ru...>]

> There are a ton of infobots still running. I'd like to wake the
> project up and get as many folks as are interested working on the same
> tree.

I started off with an infobot, but, as I'm sure everybody has found, it
needs fiddling and hacking to get working the way you want it.  After a
while, I had hacked it around so much, it was barely an infobot any
more.  However, I began to realise that the infobot architecture is just
not well designed enough for the sort of bot that we need.  Reviving
infobot is like reviving gwbasic or something - it was way cool back in
the day, but things have moved on, and there's no point in trying to go
back and fix things up.

That said, infobots are all over the place, and they are very cool bots,
and we can't just stop supporting them.  I don't want to be one of those
people that says "Rework!  Fix!  Revamp!  Start again!" and never does
anything.

When I decided that infobot just wasn't able to support what I wanted, I
started writing my own bot from scratch.  It was originally intended to
be an infobot-clone, with all the same commands, the same interface,
etc.  And, in fact, it was, by about version 0.1.  But I've carried on
hacking and fiddling, and it's kind of moved on.  I scrapped the old
infobot-style Berkeley DB interface (although the modules still work if
anybody still wants to use them) and moved onto a MySQL database.  Most
of the other infobot functions still work with maybe a slight
behavioural change here and there as users requested/complained about
them.

I know that I'm blowing my own bot's trumpet on the infobot mailing
list, but I had many long hours struggling with infobot, and the thing
that bit me the most was the way you had to restart the entire bot just
to add some punctuation in a reply.  That's the main attraction of my
new bot:  it is modular, and hotpluggable.

My bot is called Knab (recursively, "Knab is Not A Bot").

The architecture looks vaguely like so:

Knab::Source  <->  Knab::Processor <-> Knab::Modules

Knab::Source is a generic API for a "Source", which could be IRC
(implemented fully), the Console (implemented fully), a GSM modem, a
webpage, Jabber, whatever.

There is a certain article of faith of mine:

<Vhata> Spinach: rule #1 for bots
<Spinach> rule #1 for bots is Speak Only When Spoken To

Knab's architecture enforces this.  The Source "runs", waiting for
input.  When it receives input, it passes it to the processor, which
processes it, and returns a reply, or replies.  These are then returned
as output.  Thus, the bot can only speak when spoken to.

"Processing" is a matter of passing the input to each one of the loaded
"Modules" in order of priority.  The priority for each module is set as
a configuration variable, and the input gets passed to each one in turn.
These modules have a "Match" function, which gets passed the input.  If
the Match function returns False, then the Module is deemed not to care
about this input, and processing moves onto the next module.  If the
Match function returns true, then the input is passed to the Process()
function of the module, which can do whatever it wants with the input.
If the Process() function sets the 'processed' flag for this input, then
no more processing will be done, and the replies (if any) will be
output, and the bot will move on.

In this way, you can have an Ignore module right at the top of the
processing queue - it will always Match input, and it will check the
sender of the input - if this sender is in the ignore list, it will set
'processed' to true, and return - no more processing will be done, and
the sender will be effectively ignored.

The lovely thing about Knab, however, is that these modules are
hotpluggable.  You can load/unload Modules while the bot is running.
You can load a module, test it, fix an error in the code, and reload it,
and the changes will take place immediately.  This way, you don't need
to keep restarting the bot while you're developing it.

If you want to play with a Knab, you can download it from
   http://sourceforge.net/projects/knab/
Or you can join irc.zanet.net, channel # (i.e. # by itself.  Nothing
else.  Not #hash or #foo, just #), and talk to Spinach, my Knab.

If you want to play with your own Knab, I'm afraid I'm a bit lax on the
documentation.  You will need the following perl modules installed:

BerkeleyDB  Compress::Zlib  DBI  DB_File  Digest::MD5  Digest::SHA1  Fcntl
FileHandle  Geo::IP  HTML::Entities  HTML::TableContentParser
HTTP::Request::Common  IPC::Open2  LWP::UserAgent  Math::BaseCalc
Math::Trig  Net::Dict  POSIX  Socket  Symbol  WWW::Search  FileHandle
Net::IRC

A lot of which are installed with perl's base.

Here is an example of a Knab running.

<Vhata> Spinach: hi
<Spinach> sup, Vhata!
<Vhata> Spinach: lsmod
<Spinach> Vhata: Module list: Strip Auth Ignore Hate Rehash Irc Modules
          Perl MySQLSee ITime Fortune BaseConv Crypt NickOMeter RoShamBo
          GoogleCmp Slashdot REBOL MD5 Roxbury RFC Announce Morse Dict
          Jwhois Google NMBLookup Dvorak DiscDate Babel StonerName
          EtherCode Exchange TraceRoute Insult Units Greet Ping Divine
          RUWeather Swear HowFar MySQLSeen Rot13 Urban NSLookup Lotto
          Karma BashOrg Say MySQLFactoid MySQLFactoidupdate
          MySQLFactoidforget MySQLFactoidsearch Karma

<Vhata> Spinach: modinfo Exchange
<Spinach> Vhata: Exchange: Calculate exchange rate.  Usage:
          "currencies for <place>", or "exchange <value> <currency> into
          <currency>".  TLDs and country names can also be used.
<Vhata> Spinach: exchange 10 USD for .uk
<Spinach> Vhata: 10.00 (United States Dollar (USD)) makes 5.48910
          (Pound (GBP))

<Vhata> Spinach: RFC for avian
<Spinach> RFC 1149 Standard for the transmission of IP datagrams
          on avian carriers. D. Waitzman. Apr-01-1990. (Format: TXT=3329
          bytes) (Updated by RFC2549) (Status: EXPERIMENTAL)
<Spinach> RFC 2549 IP over Avian Carriers with Quality of Service.
          D. Waitzman. Apr-01-1999. (Format: TXT=9519 bytes) (Updates
          RFC1149) (Status: INFORMATIONAL)

<Vhata> Spinach: itime
<Spinach> Vhata: At the sound of the bot, the Internet Time will
          be 524.99

<Vhata> Spinach: define marmalade
<Spinach> Vhata: marmalade n : a preserve made of the pulp and
          rind of citrus fruits

<Vhata> Spinach: google for killing children to benefit canadian
        pig farmers
<Spinach> Vhata: Google found 'Canadian Coalition for Green Health
          Care', at http://www.greenhealthcare.ca/workshop22-09-00.htm

<Vhata> Spinach: modinfo Fortune
<Spinach> Vhata: Fortune: Return a fortune cookie. Usage:
          "fortune".

<Vhata> Spinach: nslookup knab.sourceforge.net
<Spinach> Vhata: knab.sourceforge.net is 66.35.250.209
<Vhata> Spinach: unload NSLookup
<Spinach> Vhata: Module NSLookup unloaded
<Vhata> Spinach: nslookup knab.sourceforge.net
<Spinach> Vhata: excuse me?
<Vhata> Spinach: load NSLookup
<Spinach> Vhata: Module NSLookup loaded

<Vhata> Spinach: foo is bar
<Spinach> Vhata: I already know stuff about what foo is
<Vhata> Spinach: literal foo
<Spinach> foo =is= baz
<Vhata> Spinach: forget foo
<Spinach> Vhata: foo is no longer an issue
<Vhata> Spinach: foo is bar
<Spinach> Vhata: gotcha
<Vhata> Spinach: foo is also bing
<Spinach> Vhata: gotcha
<Vhata> Spinach: foo has nothing on bar
<Spinach> Vhata: okay
<Vhata> Spinach: literal foo
<Spinach> foo =has= nothing on bar; and =is= bar|bing
<Vhata> Spinach: foo are also a flock of baz
<Spinach> Vhata: sure thing
<Vhata> Spinach: literal foo
<Spinach> foo =are= a flock of baz; and =has= nothing on bar; and
          =is= bar|bing
<Vhata> Spinach: foo =~ s/flock/herd/
<Spinach> Vhata: gotcha
<Vhata> Spinach: literal foo
<Spinach> foo =are= a herd of baz; and =has= nothing on bar; and
          =is= bar|bing


You'll notice that there are multiple verbs in factoids ('is', 'has',
'are', etc).  Knab has everything that an infobot has (and, indeed, is
almost indistinguishable from an infobot), but I really feel that the
monolithic design of infobot is not the way forward for a bot.

I'd love your comments/flames/patches/input?

-Jonathan


----- End forwarded message -----
-- 
Vhata Vas Hyah...
----------------------------------------------------------------------------
This email is provided "as is" and without warranty. Any express or implied 
warranties, including, but not limited to, those of merchantability and 
fitness for a particular purpose are disclaimed. In no event shall the 
authors be liable for any direct, indirect, incidental, special, exemplary,
or consequential damages arising in any way out of the reading of this email
----------------------------------------------------------------------------

Re: [infobot] Infobot rebirth?

[Jonathan H. <vh...@ru...>]

> There are a ton of infobots still running. I'd like to wake the
> project up and get as many folks as are interested working on the same
> tree.

I started off with an infobot, but, as I'm sure everybody has found, it
needs fiddling and hacking to get working the way you want it.  After a
while, I had hacked it around so much, it was barely an infobot any
more.  However, I began to realise that the infobot architecture is just
not well designed enough for the sort of bot that we need.  Reviving
infobot is like reviving gwbasic or something - it was way cool back in
the day, but things have moved on, and there's no point in trying to go
back and fix things up.

That said, infobots are all over the place, and they are very cool bots,
and we can't just stop supporting them.  I don't want to be one of those
people that says "Rework!  Fix!  Revamp!  Start again!" and never does
anything.

When I decided that infobot just wasn't able to support what I wanted, I
started writing my own bot from scratch.  It was originally intended to
be an infobot-clone, with all the same commands, the same interface,
etc.  And, in fact, it was, by about version 0.1.  But I've carried on
hacking and fiddling, and it's kind of moved on.  I scrapped the old
infobot-style Berkeley DB interface (although the modules still work if
anybody still wants to use them) and moved onto a MySQL database.  Most
of the other infobot functions still work with maybe a slight
behavioural change here and there as users requested/complained about
them.

I know that I'm blowing my own bot's trumpet on the infobot mailing
list, but I had many long hours struggling with infobot, and the thing
that bit me the most was the way you had to restart the entire bot just
to add some punctuation in a reply.  That's the main attraction of my
new bot:  it is modular, and hotpluggable.

My bot is called Knab (recursively, "Knab is Not A Bot").

The architecture looks vaguely like so:

Knab::Source  <->  Knab::Processor <-> Knab::Modules

Knab::Source is a generic API for a "Source", which could be IRC
(implemented fully), the Console (implemented fully), a GSM modem, a
webpage, Jabber, whatever.

There is a certain article of faith of mine:

<Vhata> Spinach: rule #1 for bots
<Spinach> rule #1 for bots is Speak Only When Spoken To

Knab's architecture enforces this.  The Source "runs", waiting for
input.  When it receives input, it passes it to the processor, which
processes it, and returns a reply, or replies.  These are then returned
as output.  Thus, the bot can only speak when spoken to.

"Processing" is a matter of passing the input to each one of the loaded
"Modules" in order of priority.  The priority for each module is set as
a configuration variable, and the input gets passed to each one in turn.
These modules have a "Match" function, which gets passed the input.  If
the Match function returns False, then the Module is deemed not to care
about this input, and processing moves onto the next module.  If the
Match function returns true, then the input is passed to the Process()
function of the module, which can do whatever it wants with the input.
If the Process() function sets the 'processed' flag for this input, then
no more processing will be done, and the replies (if any) will be
output, and the bot will move on.

In this way, you can have an Ignore module right at the top of the
processing queue - it will always Match input, and it will check the
sender of the input - if this sender is in the ignore list, it will set
'processed' to true, and return - no more processing will be done, and
the sender will be effectively ignored.

The lovely thing about Knab, however, is that these modules are
hotpluggable.  You can load/unload Modules while the bot is running.
You can load a module, test it, fix an error in the code, and reload it,
and the changes will take place immediately.  This way, you don't need
to keep restarting the bot while you're developing it.

If you want to play with a Knab, you can download it from
   http://sourceforge.net/projects/knab/
Or you can join irc.zanet.net, channel # (i.e. # by itself.  Nothing
else.  Not #hash or #foo, just #), and talk to Spinach, my Knab.

If you want to play with your own Knab, I'm afraid I'm a bit lax on the
documentation.  You will need the following perl modules installed:

BerkeleyDB  Compress::Zlib  DBI  DB_File  Digest::MD5  Digest::SHA1  Fcntl
FileHandle  Geo::IP  HTML::Entities  HTML::TableContentParser
HTTP::Request::Common  IPC::Open2  LWP::UserAgent  Math::BaseCalc
Math::Trig  Net::Dict  POSIX  Socket  Symbol  WWW::Search  FileHandle
Net::IRC

A lot of which are installed with perl's base.

Here is an example of a Knab running.

<Vhata> Spinach: hi
<Spinach> sup, Vhata!
<Vhata> Spinach: lsmod
<Spinach> Vhata: Module list: Strip Auth Ignore Hate Rehash Irc Modules
          Perl MySQLSee ITime Fortune BaseConv Crypt NickOMeter RoShamBo
          GoogleCmp Slashdot REBOL MD5 Roxbury RFC Announce Morse Dict
          Jwhois Google NMBLookup Dvorak DiscDate Babel StonerName
          EtherCode Exchange TraceRoute Insult Units Greet Ping Divine
          RUWeather Swear HowFar MySQLSeen Rot13 Urban NSLookup Lotto
          Karma BashOrg Say MySQLFactoid MySQLFactoidupdate
          MySQLFactoidforget MySQLFactoidsearch Karma

<Vhata> Spinach: modinfo Exchange
<Spinach> Vhata: Exchange: Calculate exchange rate.  Usage:
          "currencies for <place>", or "exchange <value> <currency> into
          <currency>".  TLDs and country names can also be used.
<Vhata> Spinach: exchange 10 USD for .uk
<Spinach> Vhata: 10.00 (United States Dollar (USD)) makes 5.48910
          (Pound (GBP))

<Vhata> Spinach: RFC for avian
<Spinach> RFC 1149 Standard for the transmission of IP datagrams
          on avian carriers. D. Waitzman. Apr-01-1990. (Format: TXT=3329
          bytes) (Updated by RFC2549) (Status: EXPERIMENTAL)
<Spinach> RFC 2549 IP over Avian Carriers with Quality of Service.
          D. Waitzman. Apr-01-1999. (Format: TXT=9519 bytes) (Updates
          RFC1149) (Status: INFORMATIONAL)

<Vhata> Spinach: itime
<Spinach> Vhata: At the sound of the bot, the Internet Time will
          be 524.99

<Vhata> Spinach: define marmalade
<Spinach> Vhata: marmalade n : a preserve made of the pulp and
          rind of citrus fruits

<Vhata> Spinach: google for killing children to benefit canadian
        pig farmers
<Spinach> Vhata: Google found 'Canadian Coalition for Green Health
          Care', at http://www.greenhealthcare.ca/workshop22-09-00.htm

<Vhata> Spinach: modinfo Fortune
<Spinach> Vhata: Fortune: Return a fortune cookie. Usage:
          "fortune".

<Vhata> Spinach: nslookup knab.sourceforge.net
<Spinach> Vhata: knab.sourceforge.net is 66.35.250.209
<Vhata> Spinach: unload NSLookup
<Spinach> Vhata: Module NSLookup unloaded
<Vhata> Spinach: nslookup knab.sourceforge.net
<Spinach> Vhata: excuse me?
<Vhata> Spinach: load NSLookup
<Spinach> Vhata: Module NSLookup loaded

<Vhata> Spinach: foo is bar
<Spinach> Vhata: I already know stuff about what foo is
<Vhata> Spinach: literal foo
<Spinach> foo =is= baz
<Vhata> Spinach: forget foo
<Spinach> Vhata: foo is no longer an issue
<Vhata> Spinach: foo is bar
<Spinach> Vhata: gotcha
<Vhata> Spinach: foo is also bing
<Spinach> Vhata: gotcha
<Vhata> Spinach: foo has nothing on bar
<Spinach> Vhata: okay
<Vhata> Spinach: literal foo
<Spinach> foo =has= nothing on bar; and =is= bar|bing
<Vhata> Spinach: foo are also a flock of baz
<Spinach> Vhata: sure thing
<Vhata> Spinach: literal foo
<Spinach> foo =are= a flock of baz; and =has= nothing on bar; and
          =is= bar|bing
<Vhata> Spinach: foo =~ s/flock/herd/
<Spinach> Vhata: gotcha
<Vhata> Spinach: literal foo
<Spinach> foo =are= a herd of baz; and =has= nothing on bar; and
          =is= bar|bing


You'll notice that there are multiple verbs in factoids ('is', 'has',
'are', etc).  Knab has everything that an infobot has (and, indeed, is
almost indistinguishable from an infobot), but I really feel that the
monolithic design of infobot is not the way forward for a bot.

I'd love your comments/flames/patches/input?

-Jonathan