in reply to Interface-clean Infobot

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.

Replies are listed 'Best First'.
Re(2): Interface-clean Infobot
by swiftone (Curate) on Jan 16, 2002 at 22:12 UTC
    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]

In Section Seekers of Perl Wisdom