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.