I think what you are looking for is Perlbot. It has the modularity you are looking for, and is very well written (in my opinion). I tried Infobot as well as another perl based bot called 'bitchbot' and I still much prefer perlbot. Anyhow, go check the link to see if that is what you need. I beleive they are also looking for developer help in getting botnet support in for perlbot if you are intrested.
djw | [reply] |
I hadn't seen this one before, but it's still not what I'm looking for. Perlbot assumes an IRC connection. Perlbot takes control of the program flow.
I'm looking for a bot that will passively wait for my program to hand it some data, give me a response to that data, and then return control of the program. Something like:
use CleanBot;
my $cleanbot = CleanBot->new('cleanbot-init.conf');
while($line=<get_data_from_a_source_the_bot_doesn't_care_about>){
my $response = $cleanbot->parse($line);
Do_something_the_bot_doesn't_care_about($response) if $response;
}
So the above loop could be used for an IRC connection, a GAIM plugin, even an FTP client if I wanted one with attitude. The bot itself would be persistent during the connection (it could remember data from line to line), and it wouldn't be hard to have it be persistent from invocation to invocation.
| [reply]
[d/l] |
The CPAN search Eliza gives four modules in three packages. The most recent (OpenFrame) was released 2002/01/04, and the list includes My::Chatbot::Eliza in the popular SOAP::Lite package.
After Compline,
Zaxo
| [reply] |
| [reply] |
I'm not entirely certain what you're after. It seems to me what you want is basically POE, but with some sort of ability to tie that to other external systems, such as IRC, or GAIM, or perhaps the web.
So maybe you could elaborate on what you're after. I'm in the midst of authoring POE::Component::IRC::Bot, which is based on PoCo::IRC, but makes bot writing simpler, however it seems you want something that's not even tied to IRC. Is that right?
If that is right, then that seems to me to be POE in a nutshell. It's an excellent architecture for bots and/or finite state machines, and so seems ideal for what you're after. | [reply] |
Yes and no. I want to have a a bot I can tie into any other program. In some cases, that may be a program I write using POE, in others it may be a different program (GAIM, for example) that already has
event handlers/event loop structure. I guess I want a bot that ISN'T the main program.
(It's probably possible to have two POE loops inside different modules, but I'm having enough trouble learning to write a main POE program without trying to figure out how to do that.)
Let me see if I can provide a spec for what I want: I want a module that I can hand a line of text to, and get a line back from (and then control of the program is outside the bot module until I call on it again), much like the Eliza interface. Since this
module would not be reading to/from a terminal, or a filehandle, or an IRC channel, or any kind of socket, etc, I could get that line of text from anywhere I wanted, and do anything I wanted with the results.
Thus, if I wanted to plop an infobot into GAIM, it is easily done. If I wanted to add a chatbot to my (theoretical) POE-based poker server setup, it's easily done. For kicks, I could have those two bots interact in some fashion, since the bot code wouldn't care where the data comes from, as long as I write whatever code is necessary to get the data from one bot to another.
The problem is that all of the Bot solutions I've seen "take control" of the interface. Perlbot, as mentioned above, talks to/from an IRC connection. Ditto for Infobot. I haven't looked into it too much, but it looks like POE::Component::IRC::Bot makes different (but still incompatible) assumptions about where the data is coming to/from.
Does that clarify things? This is the sort of problem I've encountered with several things Perl-related (probably true in other languages, but I don't go there): The interface is assumed, which means that yoru code is useless for someone who doesn't have that interface. Imagine a solitaire game (In fact, I seem to recall an instance of this in the Perl Journal a while back). You could
write a Tk-based solitaire game. OR, you could write an interface-neutral solitair module, and then a Tk interface to that module. IF someone down the line wanted to write a GTK-based solitaire, they could just write a new interface to the same codebase. If the solitaire is built in with the Tk interface, they'd have to fork it to create their new one, and may just start over from scratch.
That's what I want to avoid. There are several perl bot packages out there, I have no desire to reinvent the wheel (I've done that enough, not to mention time constraints). However, none of those bot collections will let me put those bots in a non IRC environment.
I'm all for POE, but it seems more appropriate for the structure that CALLS the bot module, not the bot module itself.
| [reply] |
(You may never see this, being a late reply)
I totally understand what you want now. I guess it just needed some super-simplification :-)
No, there's nothing like that. What we need is a base class Bot.pm, perhaps even a factory, or a feature machine. It would take "plugins" that would each get a chance to "see" the input, and when one is happy, it would return the results, whatever that may be. Yes, interesting indeed.
| [reply] |
| [reply] |