[Twisted-Python] Re: pretzel (and mudbot theory)
pretzel already seems to be gone from CVS for some unexplained reason. But maybe since it is I who had the original vision, I could possibly explain what pretzel/mudbot is suppose to be. It started when I hung out on a private mud a lot. A group of friends liked to mud and eventually we setup a private mud and all we did on it was talk. That is where Mudbot started, all it did was connect to the mud and function as any other IRC bot would do. It did some uninteresting things like executed certain commands and gave the output of them to the mud, such as 'uptime' or the like. The next step was to make it connect to more than one mud. That was completed, and intermud communication was possible just like the ry bot on #python. When the capability for 3 or more muds was hacked in, something resembling the pretzel infrastructure began to materialize. Eventually I wanted to be able to display a file easily to other people on the mud without copying or pasting. Looking through python docs I discovered 'fifos' and hacked it into mudbot. All I had to do was "cat file > mudbot/fifo" and it was chatted onto the mud. At this point I discovered that it could be possible to direct anything to this fifo and have it display on the mud. I could "tail -f logfile > mudbot/fifo" to a logfile, and it'd go to the mud. I liked this. Then I tried starting a quake server on Linux, the local output of which is text to the console, and redirecting this to the fifo made it possible for people to play quake and for there to be something of an "audience" on the mud. As we all liked to play quake, this was quite fun. Sometime around here I hacked in a little IRC support. I made it possible for IRC <---> Mud communication. Naturally, this also allowed for IRC <---> Fifo(and thus quake/logfiles)... coding in a real console interface increased the number of input/output combinations. Then I had The Idea. I decided to recode mudbot completely. It was a desperate hack, I hard-coded nearly everything. So I wrote some base mudbot code and rewrote mud/irc/console/fifo capability into separately loadable modules. At this timepoint however, I lost interest in muds because the people I hung out with decided it was more fun to harass me and my then-56k connection, so for personal reasons I didn't go back to the mud, and thus I lost interest in ALL muds, leaving Mudbot as more or less only an IRC bot on crack. So coding stopped before Mudbot's second incarnation fully materialized. And so it was left non-functional stuffed into a far corner in my home directory. So what was this idea... my idea was that everything connected to the mudbot had the capability to interact with everything else connected to the mudbot in some orderly, standard way. Descriptions of Pretzel have been so vague because we believe there's almost no limit to what it would be able to accomplish. Naturally, the first module coded for Pretzel (or UserAgent if you wish to call the module that) would be IRC input/output support. That would allow Pretzel to talk to IRC. Perhaps the second module would not be an input/output module, but a data processing module, one that would simply test the concept. When given a signal, it would output "Hello, world!". Data that comes through IRC that says "hi" would signal (perhaps just call a method of) the hello-world module, and the output of the hello-world module is returned to the IRC module. The IRC module would be told to print whatever comes from this hello-world module. The end result: <skreech> pretzel: hi <pretzel> Hello, world! Other modules would be implemented. Data-processing modules that, say, run programs and return their output, or perhaps generate a fortune using the fortune program and return that. Or, for the ry killer, a module that would simply take what is input and output it to another input/output plugin. An ry killer could consist of four pieces: 1) IRC connection to efnet 2) IRC connection to ircnet 3) IRC connection to opn 4) Mirroring plugin Where text coming in from every IRC connection would be directed towards the mirroring plugin, and the mirroring plugin would be designed to retransmit that message to every other IRC connection. So what? That could be coded with Twisted within 30 minutes, you say. Part of my goal, however, is to be able to program Pretzel's behavior without touching any code. I should be able to rip out the mirroring plugin, shove in a logfile plugin, connect the IRC connections to the logfile plugin (I keep getting the mental image of PVC pipe pluming) and make it a log-keeping bot, without seeing any code or even restarting the bot. Granted, the flexibility of the bot will be limited if you decide not to touch any code. If you use Pretzel and decide, "hmm, I want people to know my uptime." then you could code a module that adhered to the pretzel standard, shove it in to your pretzel bot, hook it up to your IRC connection, and you'd have it. The beauty of the system is that you coded it with the intention of using it on IRC, but because it is a pretzel plugin, others can use the same code to display the uptime on a Mud connection, or on Twisted.words, or heck, a Quake server. So that is my Mudbot/Pretzel theory. Thats the big idea. Any existing IRC bot ought to be able to be replaced with Pretzel and a combination of plugins, easily. Love it or hate it, give me your thoughts. But again, its mysteriously missing from CVS as of about 5am zaibach-time saturday. Gavin Cooper 'skreech'
On Sat, Oct 06, 2001 at 11:03:57AM -0500, Gavin Cooper wrote:
I removed it from CVS because glyph is going to be releasing a new version of Twisted soon and doesn't want non-functional packages in it. BTW, about your non-code touching idea, for this all that would need to be done is a simple configuration interface feature-plugin that gave the ability to add/remove plugins and whatnot.. I just had a thought. :-) Since such a configuration interface would no doubt need some sort of access control, I'm wondering if we could use the authentication bits of twisted.pb (or twisted.internet.passport.. I still don't know how any of that stuff works) without the networking stuff itself (since communication is done through the "user agents" (glyph has pointed out that this name doesn't really work either, btw)). -- Chris Armstrong | carmstro@twistedmatrix.com | cjast3@robert-morris.edu Web Page: http://purl.org/net/ChrisArmstrong
On Sat, Oct 06, 2001 at 12:50:53PM -0400, Chris Armstrong wrote:
IMHO, it's not a good idea to check in new embrionic modules to the MAIN trunk in any case... but starting a branch for it might make sense. ...and one of these days, you may want to decide that you don't want every Twisted Application in the main Twisted distribution either, particularly if they don't necessarily run on the same development cycles. i.e. you might not want to wait for a new Twisted release to publish a new pretzel plug-in... -- Kevin Turner <acapnotic@twistedmatrix.com> | OpenPGP encryption welcome The moon is waning gibbous, 82.2% illuminated, 18.9 days old.
On Sunday, October 7, 2001, at 12:18 AM, Kevin Turner wrote:
Well put. I also feel that this is a problem for Twisted as a whole, but haven't thought of a good solution yet. If you have more thoughts on how we can start to split out functionality (at least for release development cycles if not for downloads), I'd like to hear them... -- ______ you are in a maze of twisted little applications, all | |_\ remarkably consistent. | | -- glyph lefkowitz, glyph @ twisted matrix . com |_____| http://www.twistedmatrix.com/
On Sun, Oct 07, 2001 at 12:47:56AM -0500, Glyph Lefkowitz wrote:
I'll admit that I did check it in too early -- I have to get used to the fact that Twisted is Real Software now, not just a repository for our cool python code. :-)
I've discussed this with Moshe before, and I'm for it, but he's got some reasons why splitting up Twisted is not such a good thing. I still do believe that the Application-level stuff ought to be separated from the library-level stuff. Twisted: internet spread python persisted protocols tap (new applications will put their tap-generation utilities here) test enterprise (not sure..) Then we have separate packages for Twisted Web, Words, Manhole, etc etc etc. So let's define what the technical problems with splitting up Twisted are. I, being the naive person that I am, don't know what they are. :-) Oh, well I remember one issue from the discussion Moshe and I had: versioning. IMO the application-level packages should actually line up in version with the main Twisted package. Moshe said that it would be a problem when people started matching up older versions of applications with newer versions of Twisted, but I think we should just say "We _only_ support applications with the same version number as the Twisted install you are running". And if a package wants to still be on it's own release schedule, we have TwistedWeb-0.11.0-1,2,3 etc. well, I'm not sure if this will conflict with Debian versioning. Maybe we need to use some character other than "-" to separate the version numbers. Maybe TwistedWeb-1.0Twisted0.11.0 or something. whatever. =) -- Chris Armstrong | carmstro@twistedmatrix.com | cjast3@robert-morris.edu Web Page: http://purl.org/net/ChrisArmstrong
Ok, here's a sketch of what I think of as an appropriately Twisted way to do this. An IRC bot of this sort amounts to the same thing as an IRC server. Each exists in a number of rooms, has people log on and authenticate to it, send it messages, sends messages back, etc. The only difference[1] is that an IRC server talks to its clients directly through a TCP port, and the bot talks to them through some other IRC server. Now, because Twisted knows that services are independant of the transports which connect to them, it already has a "transport" abstraction. You should be able to use the IRC UserAgent as a transport in just the same way as a tcp.Port... myTwistedIrcServer.listenOn( PretzelUA("ry:irc.openprojects.net::6667:#python"), ...) Now, for the features... what I would do is let features pass a trigger regex and a callback function to the IRC server, which it would keep a list of... and the features can send messages back if and when they see fit. (This is probably only speaking to one interface of the feature-service, which may also have a web.Resource interface and a reality interface and an enterprise interface and... just because Twisted is cool like that. And, uh, isn't the phrase "it doesn't need to be distributed" pretty blasphemous around here?) As for skreech's bit about reprogramming/reconfiguring-without-editing- code-or-restarting... Well, I think that's been one of glyph's big points about Twisted ever since, well, "as long as I can remember". I do remember this because I've disagreed with him about it at times. =) Don't we still have that introduction/tutorial which demonstrates telnet-in-to-the-web-server-to-change-its-configuration? And now with manhole out there as well... Skreech, you have the benefit of experience here, as you've already done at least two incarnations of this bot. I just wanted to make sure you're appropriately and sufficiently Twisted before you start becoming Twisted. ;) "It's not a cult, I swear"-ingly yours, - Kevin (Acap) [1] "The only difference..." Well, ok, so there are a few wrinkles, i.e. certain communications which may only happen between server and client will have to be inhibited by the useragent-transport, because it may not be possible or desirable to proxy them as client-client messages on the other side. [PS] yeah, there are a whole *lot* of other details left before the approach I describe can actually happen. Which is why I introduced it as a "sketch" instead of code. =) -- Kevin Turner <acapnotic@twistedmatrix.com> | OpenPGP encryption welcome The moon is waning gibbous, 81.6% illuminated, 18.9 days old.
On Sat, Oct 06, 2001 at 11:03:57AM -0500, Gavin Cooper wrote:
I removed it from CVS because glyph is going to be releasing a new version of Twisted soon and doesn't want non-functional packages in it. BTW, about your non-code touching idea, for this all that would need to be done is a simple configuration interface feature-plugin that gave the ability to add/remove plugins and whatnot.. I just had a thought. :-) Since such a configuration interface would no doubt need some sort of access control, I'm wondering if we could use the authentication bits of twisted.pb (or twisted.internet.passport.. I still don't know how any of that stuff works) without the networking stuff itself (since communication is done through the "user agents" (glyph has pointed out that this name doesn't really work either, btw)). -- Chris Armstrong | carmstro@twistedmatrix.com | cjast3@robert-morris.edu Web Page: http://purl.org/net/ChrisArmstrong
On Sat, Oct 06, 2001 at 12:50:53PM -0400, Chris Armstrong wrote:
IMHO, it's not a good idea to check in new embrionic modules to the MAIN trunk in any case... but starting a branch for it might make sense. ...and one of these days, you may want to decide that you don't want every Twisted Application in the main Twisted distribution either, particularly if they don't necessarily run on the same development cycles. i.e. you might not want to wait for a new Twisted release to publish a new pretzel plug-in... -- Kevin Turner <acapnotic@twistedmatrix.com> | OpenPGP encryption welcome The moon is waning gibbous, 82.2% illuminated, 18.9 days old.
On Sunday, October 7, 2001, at 12:18 AM, Kevin Turner wrote:
Well put. I also feel that this is a problem for Twisted as a whole, but haven't thought of a good solution yet. If you have more thoughts on how we can start to split out functionality (at least for release development cycles if not for downloads), I'd like to hear them... -- ______ you are in a maze of twisted little applications, all | |_\ remarkably consistent. | | -- glyph lefkowitz, glyph @ twisted matrix . com |_____| http://www.twistedmatrix.com/
On Sun, Oct 07, 2001 at 12:47:56AM -0500, Glyph Lefkowitz wrote:
I'll admit that I did check it in too early -- I have to get used to the fact that Twisted is Real Software now, not just a repository for our cool python code. :-)
I've discussed this with Moshe before, and I'm for it, but he's got some reasons why splitting up Twisted is not such a good thing. I still do believe that the Application-level stuff ought to be separated from the library-level stuff. Twisted: internet spread python persisted protocols tap (new applications will put their tap-generation utilities here) test enterprise (not sure..) Then we have separate packages for Twisted Web, Words, Manhole, etc etc etc. So let's define what the technical problems with splitting up Twisted are. I, being the naive person that I am, don't know what they are. :-) Oh, well I remember one issue from the discussion Moshe and I had: versioning. IMO the application-level packages should actually line up in version with the main Twisted package. Moshe said that it would be a problem when people started matching up older versions of applications with newer versions of Twisted, but I think we should just say "We _only_ support applications with the same version number as the Twisted install you are running". And if a package wants to still be on it's own release schedule, we have TwistedWeb-0.11.0-1,2,3 etc. well, I'm not sure if this will conflict with Debian versioning. Maybe we need to use some character other than "-" to separate the version numbers. Maybe TwistedWeb-1.0Twisted0.11.0 or something. whatever. =) -- Chris Armstrong | carmstro@twistedmatrix.com | cjast3@robert-morris.edu Web Page: http://purl.org/net/ChrisArmstrong
Ok, here's a sketch of what I think of as an appropriately Twisted way to do this. An IRC bot of this sort amounts to the same thing as an IRC server. Each exists in a number of rooms, has people log on and authenticate to it, send it messages, sends messages back, etc. The only difference[1] is that an IRC server talks to its clients directly through a TCP port, and the bot talks to them through some other IRC server. Now, because Twisted knows that services are independant of the transports which connect to them, it already has a "transport" abstraction. You should be able to use the IRC UserAgent as a transport in just the same way as a tcp.Port... myTwistedIrcServer.listenOn( PretzelUA("ry:irc.openprojects.net::6667:#python"), ...) Now, for the features... what I would do is let features pass a trigger regex and a callback function to the IRC server, which it would keep a list of... and the features can send messages back if and when they see fit. (This is probably only speaking to one interface of the feature-service, which may also have a web.Resource interface and a reality interface and an enterprise interface and... just because Twisted is cool like that. And, uh, isn't the phrase "it doesn't need to be distributed" pretty blasphemous around here?) As for skreech's bit about reprogramming/reconfiguring-without-editing- code-or-restarting... Well, I think that's been one of glyph's big points about Twisted ever since, well, "as long as I can remember". I do remember this because I've disagreed with him about it at times. =) Don't we still have that introduction/tutorial which demonstrates telnet-in-to-the-web-server-to-change-its-configuration? And now with manhole out there as well... Skreech, you have the benefit of experience here, as you've already done at least two incarnations of this bot. I just wanted to make sure you're appropriately and sufficiently Twisted before you start becoming Twisted. ;) "It's not a cult, I swear"-ingly yours, - Kevin (Acap) [1] "The only difference..." Well, ok, so there are a few wrinkles, i.e. certain communications which may only happen between server and client will have to be inhibited by the useragent-transport, because it may not be possible or desirable to proxy them as client-client messages on the other side. [PS] yeah, there are a whole *lot* of other details left before the approach I describe can actually happen. Which is why I introduced it as a "sketch" instead of code. =) -- Kevin Turner <acapnotic@twistedmatrix.com> | OpenPGP encryption welcome The moon is waning gibbous, 81.6% illuminated, 18.9 days old.
participants (4)
-
Chris Armstrong -
Gavin Cooper -
Glyph Lefkowitz -
Kevin Turner