Menu
▾
▴
infobot-devel — Infobot use and development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(37) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(17) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(5) |
| 2007 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(37) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(13) |
Apr
|
May
(4) |
Jun
|
Jul
(3) |
Aug
(10) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2009 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(8) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(2) |
Feb
|
Mar
(6) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James O'K. <jo...@mi...> - 2005-04-18 15:39:46
|
If someone is going to be compiling a list of bot comparisons, add Knab to the list. http://sourceforge.net/projects/knab I picked Knab because it was easy to extend. I've added a module to it so that it's available via AIM as well as IRC. In addition, I was able to replace the source of factoid from SQL to something else. I've submitted a patch with some of these changes back to the author, but I don't think he's put them into a released version yet. -james |
|
From: Michael H. C. <mi...@li...> - 2005-04-18 14:56:53
|
ho...@mi... wrote: > On Mon, 18 Apr 2005, Michael H. Collins wrote: > >> Dunno but I have been comparing infobot and flooterbuck and have begun >> using flooterbuck almost exclusivly > > > Michael - can you briefly explain why? What's it got that infobot > hasn't? Does it preserve all infobot's functionality? It certainly > looks a bit more active, but latest release is still over a year > ago... Yes. I am frustrated with devel on all the infobots. Not being a coder about all I can do is run em and report bugs. Flooterbuck has a few modules thrown in that infobot does not come with unless I am missing something. my best one is running on irc.taphouse.org #subgenius and his name is bobot -- Michael H. Collins Admiral, Penguinista Navy http://linuxlink.com /"\ ASCII Ribbon Campaign \ / No HTML/RTF in email x No Word docs in email / \ Respect for open standards In a related story, the IRS has recently ruled that the cost of Windows upgrades can NOT be deducted as a gambling loss. |
|
From: Michael H. C. <mi...@li...> - 2005-04-18 14:48:58
|
Tim Riker wrote: > Care to elaborate on the comparison? Also have you looked at blootbot as > well or just flooterbuck? I looked at blootbot only briefly. I am not a coder and barely a hacker. The comparison went like this. Set up infobot and run it. Time it till it goes belly up. repeat. Do same for flooterbuck. Which one runs longest before it dies? Use that one. Also some times when infobot dies it hoses some of the dbs and that funcionality dissapears. flooterbuck seems much less prone to this. > > Michael H. Collins wrote: > >>ho...@mi... wrote: >> >> >>>So, what happened to all this? As I understand it, Tim took over >>>project leadership for infobot from Kevin last August, but I don't >>>see any activity since then. We moved into a situation where the >>>community half loved on its old mailing list (this one) and half on >>>sf.net. Then I didn't hear anything more, unless I'm missing >>>activity somewhere. It's really dead this time? >> >> >>Dunno but I have been comparing infobot and flooterbuck and have begun >>using flooterbuck almost exclusivly >> >> >> >> > > > -- Michael H. Collins Admiral, Penguinista Navy http://linuxlink.com /"\ ASCII Ribbon Campaign \ / No HTML/RTF in email x No Word docs in email / \ Respect for open standards In a related story, the IRS has recently ruled that the cost of Windows upgrades can NOT be deducted as a gambling loss. |
|
From: <ho...@mi...> - 2005-04-18 14:27:03
|
On Mon, 18 Apr 2005, Michael H. Collins wrote: > Dunno but I have been comparing infobot and flooterbuck and have begun using > flooterbuck almost exclusivly Michael - can you briefly explain why? What's it got that infobot hasn't? Does it preserve all infobot's functionality? It certainly looks a bit more active, but latest release is still over a year ago... |
|
From: Tim R. <Ti...@Ri...> - 2005-04-18 14:21:00
|
Care to elaborate on the comparison? Also have you looked at blootbot as well or just flooterbuck? Michael H. Collins wrote: > ho...@mi... wrote: > >> So, what happened to all this? As I understand it, Tim took over >> project leadership for infobot from Kevin last August, but I don't >> see any activity since then. We moved into a situation where the >> community half loved on its old mailing list (this one) and half on >> sf.net. Then I didn't hear anything more, unless I'm missing >> activity somewhere. It's really dead this time? > > > Dunno but I have been comparing infobot and flooterbuck and have begun > using flooterbuck almost exclusivly > > > > -- Tim Riker - http://rikers.org/ - Ti...@De... Embedded Linux Technologist BZFlag maintainer - http://BZFlag.org/ - for fun! |
|
From: David C. <da...@ca...> - 2005-04-17 20:30:30
|
Tim Riker wrote: > How many folks on the list still use the original infobot codebase? I do, although with some additions. The main difference between mine and 0.45.3 is my "karma comments" patch, available on my web site at http://www.cantrell.org.uk/david/tech/ -- David Cantrell | Official London Perl Mongers Bad Influence Sobol's Law of Telecom Utilities: Telcos are malicious; cablecos are simply clueless. |
|
From: <ho...@mi...> - 2005-04-17 14:04:40
|
On Sat, 16 Apr 2005, Tim Riker wrote:
> Well, at the moment I still consider the old list the official one. I'll
> holler if that changes. I certainly appreciate the archive. Thanx!
Aw thanks :)
>>> How many folks on the list still use the original infobot codebase?
>>
>> Me.
>
> Interesting. Why not flooterbuck or blootbot?
Truth be told, inertia. I hacked my infobot to do stuff I wanted as
well, and I'm not hacker, and it was gruesome, and certainly not
worth contributing back to the community. Silly stuff. I looked at
bloodbot once, and rejected it for some reason I can't remember, and
had never heard of flooterbuck until you mentioned it yesterday.
Yes, I haven't kept up. If someone somewhere could map out a brief
set of can's and can't's for each bot, and requirements for each, or
point to one that exists, that would be great. Presumably they don't
all have to same functionality else they wouldn't all exist? (I ask
naively, ignoring the fact the forks happen because of people, not
just needs)....
What I want from a bot is mostly silliness. Optional, not required
mode, and the ability to pick up 5 years of dross and repeat it back
to amusing effect. And realising that with some clever constructs you
can make it do knock-knock jokes without programming. And making it
impersonate Sean Connery when answering ("be sean"). I suspect I'm not
one of the most useful or serious contributors to the bot community.
Can I bounce the implication I'm assuming is behind your question back
at you then: if the bots all overlap in functionality and requirements,
why do you want to keep infobot going?
>>> Personally, I like having an SQL back end. I use SQLite so that it's
>>> still just a local file. SQLite is still a big step up from db files.
>>
> Exactly the reasons that I use SQLite. It is just a local file and no
> root level access is required.
Point taken re. SQLite. I suppose I'm iffy about it because I had to
change from SQLite to MySQL when my music player (amarok) kept
corrupting my SQLite database irretrievably when crashing. I'm sure
an app bug but...
|
|
From: David A. D. <ha...@gn...> - 2005-04-17 05:48:49
|
> Well, at the moment I still consider the old list the official one. > I'll holler if that changes. I certainly appreciate the archive. > Thanx! Please please PLEASE do not switch the mailing list from what it is now, to that bastardized, broken, useless hacked-up Mailman that SF.net is using.. and here are a few: 1.) No way to modify subscription parameters (digest, et al) 2.) No way to see an entire month's posting, sorted by author, thread, or date. 3.) No mbox downloads, to search and read offline. Like most of the SF.net "services", they took a standard piece of software, crippled it, stripped out the useful features, and put it into production (cvs and mailman being the two largest ones I can think of at this point). David A. Desrosiers de...@gn... http://gnu-designs.com |
|
From: William S. L. I. <vla...@gm...> - 2005-04-17 02:31:16
|
I still use it, and would like to keep using it. I'm sql agnostic, but since I have MySQL setup on all of my servers, I'd like to see it be able to use that as well... -----Original Message----- From: inf...@li... [mailto:inf...@li...] On Behalf Of Tim Riker Sent: Saturday, April 16, 2005 3:59 PM To: ho...@mi... Cc: inf...@me...; inf...@li... Subject: Re: [infobot] unsubscribing? I've done some very minor commits in the CVS tree on SF. I've tried a few times to contact lenzo again, but without success. I'd like to move the old list over to the new one, and move [www.]infobot.org over to point to SF. Then the plan is to start collecting useful bits from the infobot forks and make a merged useful bot. As I never heard back from lenzo again, the flooterbuck folks seem to be anti-SF, and the blootbot project is progressing by itself, I've not made any progress on starting a merge. I've been working on blootbot in the mean time. How many folks on the list still use the original infobot codebase? How many would use it if it became active again? Personally, I like having an SQL back end. I use SQLite so that it's still just a local file. SQLite is still a big step up from db files. -- Tim Riker - http://rikers.org/ - Ti...@De... Embedded Linux Technologist BZFlag maintainer - http://BZFlag.org/ - for fun! ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Infobot-devel mailing list Inf...@li... https://lists.sourceforge.net/lists/listinfo/infobot-devel Support in #botpark on irc.freenode.net |
|
From: Tim R. <Ti...@Ri...> - 2005-04-17 00:02:29
|
ho...@mi... wrote: > On Sat, 16 Apr 2005, Tim Riker wrote: > >> I'd like to move the old list over to the new one, and move >> [www.]infobot.org over to point to SF. > > OK. I provided the original project with the mail archive (not the > list itself), as linked from www.infobot.org. If the project does take > off again, can someone tell me whether they want it to continue, etc.? > It's a bit more searchable/usable than sf.net archive but... *shrug*. Well, at the moment I still consider the old list the official one. I'll holler if that changes. I certainly appreciate the archive. Thanx! > But you have access to www.infobot.org to change it? I see it's > still registered to Kevin as a domain until December 2006. I was hoping lenzo would change it to point to SF. He can keep the registration. I'd be happy to take that over if he wishes, but I assume he'll want to keep it. >> How many folks on the list still use the original infobot codebase? > > Me. Interesting. Why not flooterbuck or blootbot? >> How many would use it if it became active again? > > Probably me, if it didn't change radically in functionality. > >> Personally, I like having an SQL back end. I use SQLite so that it's >> still just a local file. SQLite is still a big step up from db files. > > Personally, I'd definitely *not* like it to depend on an SQL backend. > I like its simplicity, and many people will want to run this from a > shell account where they don't have root access, or access to an SQL > db. I like it to be runnable from a single directory - that was > always the attraction. Exactly the reasons that I use SQLite. It is just a local file and no root level access is required. Unlike db files, it supports full SQL syntax. This adds a lot of power for searching the tables. This new power is _not_ available if all the code still has to work with db files. We kept db support in blootbot for a long time till the sqlite interface worked. Then we found no good reason to keep db support, and lots of reasons to use the power of SQL queries. -- Tim Riker - http://rikers.org/ - Ti...@De... Embedded Linux Technologist BZFlag maintainer - http://BZFlag.org/ - for fun! |
|
From: <ho...@mi...> - 2005-04-16 22:41:16
|
On Sat, 16 Apr 2005, Tim Riker wrote: > I'd like to move the old list over to the new one, and move > [www.]infobot.org over to point to SF. OK. I provided the original project with the mail archive (not the list itself), as linked from www.infobot.org. If the project does take off again, can someone tell me whether they want it to continue, etc.? It's a bit more searchable/usable than sf.net archive but... *shrug*. But you have access to www.infobot.org to change it? I see it's still registered to Kevin as a domain until December 2006. > How many folks on the list still use the original infobot codebase? Me. > How many would use it if it became active again? Probably me, if it didn't change radically in functionality. > Personally, I like having an SQL back end. I use SQLite so that it's > still just a local file. SQLite is still a big step up from db files. Personally, I'd definitely *not* like it to depend on an SQL backend. I like its simplicity, and many people will want to run this from a shell account where they don't have root access, or access to an SQL db. I like it to be runnable from a single directory - that was always the attraction. |
|
From: Tim R. <Ti...@Ri...> - 2005-04-16 21:00:25
|
I've done some very minor commits in the CVS tree on SF. I've tried a few times to contact lenzo again, but without success. I'd like to move the old list over to the new one, and move [www.]infobot.org over to point to SF. Then the plan is to start collecting useful bits from the infobot forks and make a merged useful bot. As I never heard back from lenzo again, the flooterbuck folks seem to be anti-SF, and the blootbot project is progressing by itself, I've not made any progress on starting a merge. I've been working on blootbot in the mean time. How many folks on the list still use the original infobot codebase? How many would use it if it became active again? Personally, I like having an SQL back end. I use SQLite so that it's still just a local file. SQLite is still a big step up from db files. -- Tim Riker - http://rikers.org/ - Ti...@De... Embedded Linux Technologist BZFlag maintainer - http://BZFlag.org/ - for fun! |
|
From: <ho...@mi...> - 2005-04-16 18:37:19
|
So, what happened to all this? As I understand it, Tim took over project leadership for infobot from Kevin last August, but I don't see any activity since then. We moved into a situation where the community half loved on its old mailing list (this one) and half on sf.net. Then I didn't hear anything more, unless I'm missing activity somewhere. It's really dead this time? On Sun, 8 Aug 2004, Tim Riker wrote: > I've talked to Kevin briefly, but we did not talk about the email lists yet. I'll ping him again about that. > > SF has added searching of email lists since I last looked. They will also import old email archives. Do you have mbox format archives for the list? I'll work towards getting the complete archives up on SF. Then I'll feel more comfortable actually moving to the new list. Let's live with the current dual list mess for a few more days. Sound ok? |
|
From: Shevek <sh...@an...> - 2004-08-10 20:26:04
|
On Wed, 2004-08-04 at 18:57, Tim Riker wrote: > I heard from lenzo. I'll keep everyone informed as we chat. > 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. Forking sucks. > 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. As the author of one of the forks (Amethyst), you're welcome to use anything you like from her. However, I don't have the time to commit to any development. Well, technically, Amethyst was a reimplementation from scratch of the infobot spec, so people will probably be uncomfortable with her, but ... It's all free so have a look. > I have nothing against adding more protocols, but these are the main > ones I would like to see. Protocols I did. > 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. Forking sucks. S. |
|
From: David A. D. <ha...@gn...> - 2004-08-08 16:18:24
|
> SF has added searching of email lists since I last looked. They will also > import old email archives. Do you have mbox format archives for the list? > I'll work towards getting the complete archives up on SF. Then I'll feel > more comfortable actually moving to the new list. Let's live with the > current dual list mess for a few more days. Sound ok? My main beef with the way SF manages their mailing lists, is that they don't provide a way to download the list archives for a certain month or for a full period. They're using this hacked-up Mailman interface in an effort to simply get users to subscribe, but they don't really provide any useful mailing list tools that go with that Mailman instance. I've been complaining about this to them for about 3 years, and they don't seem to want to change it. If the lists move to SF.net exclusively, I think I'll be joining the ranks of those who unsubscribe as well. It just isn't a useful environment anymore... they keep crippling things. The other thing, which you mention, and I still can't find.. is the ability to search the lists using rich sets of keywords, regexen, and boolean targets. This is a huge crippling chasm in their infrastructure (and also one thing I've been ranting about for years with them). They've just recently added Yahoo! search, but it doesn't really work as well as some of the other generic search algorithms I've seen and used personally. Just my 0.02 euros on the matter. d. |
|
From: <ho...@mi...> - 2004-08-08 14:16:01
|
On Sun, 8 Aug 2004, Rocco Caputo wrote: > I hate doing this, but I haven't found another way. > > How do I change my subscription address on this list? > > My e-mail address changed several months ago, but I haven't found a > way to change it in the list. Neither metronomicon.com nor the > mailing list messages include instructions, and the various standard > listserv commands and addresses haven't worked. I believe it's Majordomo, not Listserv - so you send commands in the body of the text, not the subject. So to subscribe send a mail to maj...@me... (at a guess) with this in the body: subscribe infobot-dev To unsubscribe send: unsubscribe infobot-dev from the address you wish to unsub. If you don't have access to send from that address anymore, send unsubscribe infobot-dev <email address> and pray that a listadmin receives and responds to the mail there. Note I don't run the list, so I'm guessing. --- With regard to archiving, no-one responded with what they'd like me to do with the infobot archive. Seems to me the list is forking even if the project isn't - I see mails from metronomicon that respond to messages I haven't seen, which are presumably going to the sourceforge list only, and replies going to both. Tim, if this is so can you let me know what you decide please (presuming you're now in charge and no response from Kevin has come)? The archive's getting in a muddle with two sometimes-unsyncronised lists and part double-posting. Status as per my last message to this list :) |
|
From: Rocco C. <rc...@po...> - 2004-08-08 05:48:17
|
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/ |
|
From: <ki...@sw...> - 2004-08-06 05:09:36
|
alright i think i need to contribute another perspective here, as a user and not a developer, i run an infobot in its pure unadulterated form... what i needed was an 'encyclopaedic' bot that is 1) simple to get running 2) low on maintenance 3) would do all the work by itself, while i leave my channel unattended for looong periods of time. i don't see much traffic there, but that is not much of a concern to me... i settled on a stable release of infobot for this purpose and it has been running for a very long time and works quite adequately. not perfect, but closer to perfect than anything else that i have tried in a very subjective sense... now, i am no code-gremlin, and my development skills are rather basic if any. i would like to see the current functions of infobot enhanced, while at the same time, it should still be recognisable as the infobot that i know now, for the one reason being that what it has to offer now, is basically the framework that i find suitable for my needs. else i might have implemented some other product. frankly, i find infobot in its current incarnation the closest thing to the ideal, as i have said before... per example... whether infobot speaks when spoken to, or just comments on whatever is heard, should remain a matter of implementation choice. cheerz! -- http://swords.web.za/ ki...@sw... <:::::::::::::]====o |
|
From: Tim R. <Ti...@Ri...> - 2004-08-04 20:40:37
|
Have you used sqlite? It uses a single local file to store all the tables in a database. No separate RDBMS process is needed. http://www.sqlite.org/ There are Perl DBI modules for it of course. SQL as an option, but not a requirement means that you cannot take good advantage of the search features of the SQL server. So you'd get the bloat without any real improvement. Using an sqlite file instead of multiple dbm files means that you do get the sql features while keeping simple administration. David Cantrell wrote: > Tim Riker wrote: > >> 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. > > I'd like a SQL backend as an option, but requiring an RDBMS would, IMO, > be a Bad Thing. > > I believe that dipsy (and #london.pm infobot) already has one, and > expect that whoever is caring for it this month is on one of these lists. -- Tim Riker - http://rikers.org/ - Ti...@De... Linux Technologist - Ti...@TI... - http://www.TI.com/ BZFlag maintainer - http://BZFlag.org/ - for fun! |
|
From: Paul L. A. <pl...@so...> - 2004-08-04 19:47:23
|
Tim Riker writes: > Some thoughts on the way forward (in no particular order): > 2) we need a new framework to better support tons of modules. We also need a far more flexible configuration format. One that is capable of specifying (with relative ease, probably using inheritance and over-riding) that on server X, channel Y, the bot need not be addressed for most commands but must be addressed for command Z. It would probably be good if extension modules, if enabled by the configuration, can pass back to the main program what to look for rather than having stuff like /Zippy/ coded into the main program. Resolving conflicts would require some thought (probably first registered, first tried). At least that way people could submit extension modules that don't require a patch to the main routine. In fact, it would be even better if that was done in the configuration file. So where you enable Zippy you also specify that it should look for /Zippy/i or /Be Zippy/ or whatever. You'd have to analyse everything the bot and existing extensions currently look for to generalize it as much as possible without overcomplicating it. If no search criteria are specified then hardwired defaults in the module are used instead. That way you don't have to do anything unless two modules conflict or you don't like what the bot is looking for, and if the module is searching for something impossible to specify in whatever syntax we use that's OK too. > 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. Not everyone is in a position to get MySQL or sqlite set up for them. It's rare, but it happens. But most *nix boxes will allow even unprivileged users to call ndbm/gbdm/db. It would be nice if it were possible to choose at configure time which to use. That would mean abstracting the existing db calls. It would also permit alternative SQL databases to be added as required. > 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. But the reason there were so many forks is that nobody could agree on how to proceed. I suspect you may end up with more arguments than progress... > 5) I'd like to add email, web, and local admin interfaces at least. email > for things like CIA does now: Local admin interface can be as simple as listening on a port on the loopback address. Use your favourite telnet program and just type "forget Bush". For the local interface the bot would react exactly as if it had been /msgd - no need to address it no matter what the config says. -- Paul Allen Softflare Support |
|
From: Paul L. A. <pl...@so...> - 2004-08-04 19:20:58
|
Jonathan Hitchcock writes: > 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 The reasons it was chosen long ago are still valid today. Available on just about all platforms, including one not widely known outside the UK. Regexes well-integrated. Portability. Well-suited to the task. A large pool of people who are familiar with it (more than know Python or Ruby or Java, or...) None of that is sufficient reason to prevent a re-implementation in Python, but you may find yourself with fewer people willing or able to help out. > 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. They were so obvious I used them to explain to you why RP or SOAP was a totally unnecessary complication. > 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. Abstraction is sometimes a bad thing. Especially in a bot that is designed to learn from public and private messages and to take commands from public and private messages from those who have privileges. To come up with some cumbersome encoding for inter-bot communications would be pointless and silly. The bot learns if I say on channel "X is Y". It learns if I send it a message that "X is Y". I see no reason to not use that for inter-bot communication and instead adopt some bizarre encoding like "Subject: X; verb: is; object: Y". What's the point? Only to extend the range of messages one bot can send another, but I don't want one bot being able to make another bot do things that I cannot do directly, not even if both are under my control. So any extension would have to be usable by me directly on an IRC channel, and therefore the bot would have to be able to parse plain old English, just as it does now. The only thing it would achieve is the bot having to have two sets of parsers each of which had to be updated any time a new command was added. A lot of work for no gain. >> 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. I was making the point that if the bots can communicate with people they can communicate with each other without needing PB. If PB is so wonderful and so much better than bots using IRC or Yahoo to talk to each other then we should scrap IRC and Yahoo. > I'm suggesting extending the original design and embracing new methods. I have no problem with extending the design with useful and necessary features. I have no problem if a new method offers significant advantages. I don't see any point in adding unnecessary bloat just for the hell of it. > I'm also clearly pissing people off by suggesting that infobot is not > perfect. It's far from perfect. Like any software that has evolved from simple beginnings it would benefit from a redesign. That's no excuse to throw in a kitchen sink just because you have a spare one sitting around doing nothing. >> 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. You missed the point. If PB or SOAP are so damned wonderful and offer some form of inter-bot communication you absolutely CANNOT do over IRC or Yahoo then clearly we should migrate to one of them for chatting with each other instead of using IRC and Yahoo. Yes, it would provide intercommunication in a neutral format rather than both bots having to pick a shared messaging method, but if I can't get the guy running the other bot to agree to using either Yahoo or AIM or whatever, will I agree with how he runs his bot in general? >> 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. 1) Many people don't want their bots doing this. 2) If they want to, they can have the bots communicate using Yahoo or whatever other additional messaging protocols there are modules for. Some people will want the Yahoo module so their bots can talk to PEOPLE on Yahoo. Nobody wants a PB module so their robot can talk to PEOPLE. Its only use would be for bots to talk to other bots. So that means coding an extra module, more bloat, more holes in the firewall, for something that could be done with one of the modules some people WILL want. Even a mail module would make some sort of sense because PEOPLE could use that too. 3) Allowing connections to multiple IRC servers would be far more useful considering this is, right now, primarily an IRC bot. I'd like to be able to have a bot hang out on a couple of servers without having to run two instances of it with separate configuration files. With that ability then bots on different IRC networks can communicate without needing Yahoo because one or more of them can be on more than one network. It may even be that this is the main reason people have for wanting bots to communicate in some way other than IRC because right now they have to run two instances of the bot to have it on different servers. So there are two alternatives (multiple IRC network or using something like Yahoo) for inter-bot communication that are desirable in their own right because they would be used by people who have no desire to have their bot talk with other bots. You cannot say the same thing about a PB/SOAP solution because it has no other utility. > Look, forget it. Go ahead. I'll sit in the background until you start > developing. I submitted a few patches a while ago. Things went dead so I stopped, waiting on Kevin finishing his rewrite. Since Kevin has shown signs of life recently, perhaps he'll finish the rewrite and I'll submit more patches and extensions. -- Paul Allen Softflare Support |
|
From: David C. <da...@ca...> - 2004-08-04 19:01:20
|
Tim Riker wrote:
> 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.
I'd like a SQL backend as an option, but requiring an RDBMS would, IMO,
be a Bad Thing.
I believe that dipsy (and #london.pm infobot) already has one, and
expect that whoever is caring for it this month is on one of these lists.
--
David Cantrell | Reality Engineer, Ministry of Information
It requires zero configuration once you're configured properly
-- pudge, talking about Rendezvous (zeroconf) in Jagwyre
|
|
From: Jonathan H. <vh...@ru...> - 2004-08-04 18:19:26
|
On Wed 2004-08-04 (19:09), Paul L. Allen wrote: > Or to put it another way, can anyone conceive of a legitimate type of > inter-bot message that would not also be legitimate (in at least some > situations) when given to the bot by a human (privileged to do so) in > public or in private? So we don't need a special inter-bot message > format. It's rather the other way around. There is no type of inter-bot messages that aren't legitimate when coming from a (sufficiently authorised) human, but there *are* legitimate human messages that shouldn't be accepted from other bots. The most obvious example is avoiding bot-loops, where each bot tries to reply to the reply it just got from the other one. Because bots are trainable to behave in certain ways, having one bot trust another bot is slightly dangerous. If it is possible for me to train a bot to say something to another person, then I can train him to say something to another bot. If a bot trusts another bot more than he trusts me, I can use this method to get around the security. Thus, I think, bots should trust other bots as much as J. Random User at maximum, and possibly a lot less. |
|
From: Paul L. A. <pl...@so...> - 2004-08-04 18:09:48
|
Joe McMahon writes: > 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. Having bots able to communicate with each other is a good idea (provided it can be turned off if desired). All of the suggested messaging protocols have some equivalent of an IRC channel (group talk) and private messaging. It makes sense to layer any inter-bot comms over the private messaging of whichever messaging medium it's using. That makes it very, very easy to implement: if the messaging medium supports private messages then bots can communicate with each other. It also avoids having to open yet more ports in a firewall just so bots can talk to each other when you had to open up IRC, or Yahoo, or whatever so the bot could work. Do we need some pre-agreed command/data/whatever encoding? It's tempting to invent one, but you can drive a robot (feed it facts, make it forget facts, get it to join or leave channels) with private messages. After all, its whole reason for existence is to learn from what its told and to take orders from those permitted to give them. Or to put it another way, can anyone conceive of a legitimate type of inter-bot message that would not also be legitimate (in at least some situations) when given to the bot by a human (privileged to do so) in public or in private? So we don't need a special inter-bot message format. What does not make sense is adding RB or SOAP or whatever just so bots can talk to each other. > 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 agree entirely with Nat. However, I am far from convinced that "intelligent" is applicable to the suggestions that were made. Adding RP or SOAP just so bots can talk to each other is a needless complication and unnecessary bloat. If you want cross-server communication then give bots the ability to connect to more than one server. If you want, for some bizarre reason, to drive the bot from a desktop app then let it sit on a local port that you can telnet to and talk to it just as though you were on IRC private messaging it (except it should never have to be addressed, even if the configuration for IRC says it must be). Then you don't even need a special app, or to learn a different set of commands. -- Paul Allen Softflare Support |
|
From: Tim R. <Ti...@Ri...> - 2004-08-04 17:57:41
|
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. 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. 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. 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. 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 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. -- Tim Riker - http://rikers.org/ - Ti...@De... Linux Technologist - Ti...@TI... - http://www.TI.com/ BZFlag maintainer - http://BZFlag.org/ - for fun! |
6 messages has been excluded from this view by a project administrator.
