On Wed, Sep 25, 2002 at 03:34:26PM -0500, James Edward Gray II wrote: > '2.1 Do similar modules already exist in some form?' [snip] > My newly coded module is a Multiplexed Non-blocking I/O Telnet Server. > It was written with an eye towards serving MUDs, MUSHes, and similar > games, because that's what I intend to write with it, but it's not > really limited to those. Knowing that, here's what I found: > > IO::NonBlocking - (Found via search, but I can't seem to locate it in > the module list.) This pretty close to what I built, excepting wildly > different interfaces. This module seems very generic, though it does > mention 'game servers' once in the README.
You mention your module is a telnet server. Is that accurate? Does it actually understand the telnet protocol? IO::NonBlocking isn't a server, it's a method of implementing a server; there's quite a bit more you'd have to add to do so. It appears you could implement Server::MUServer using IO::NonBlocking, but Server::MUServer isn't a replacement for IO::NonBlocking. Thus, they fit two different problems, though they do cover some common ground. > That's the only match I can be sure on. I admit that my CPAN skills > are still very poor though, so if I missed 5,000 matches or even 1, > please enlighten me. I looked for telnet servers and found a few things. There's an OurNet namespace for some sort of BBS system, and an Anarres::Mud::Driver namespace for some MUD modules. The last one is an oddity; there are no modules below Anarres::Mud::Driver as far as I could tell. It makes me wonder what the Anarres namespace is for. > So, my question (Finally!) is, should I even bother submitting this? > I'm not trying to add to module confusion, I just thought others might > like to use my code. If it will help, I'll submit it. If it's already > been covered, I'll keep it to myself. I have no experience here > though, so I could use opinions. Should I maybe even consider slanting > mine more towards game serving and then submit it? Any opinions are > appreciated. It's hard to say without more specific information. It sounds like it does something slightly different from what's available. That doesn't necessarily mean you should submit it, though. The criteria I would use in this case is whether or not the module is basically a program or a module; i.e. can the module be mixed in with others easily, or do you call it with whatever parameters it needs, and then let it do its thing? For a specific example, what happens when a user sends data? Does Server::MUServer call back (at some point) to subroutines you've given it, or does it handle it all internally, with some sort of hard-wired logic? Notice how IO::NonBlocking calls back to predefined methods for events; something like that would be required to make it generic enough for general use. > '2.5 Select a name for the module.' > > I thought I had this under control, but after reading a little, I'm not > so sure. (Since it seems to change the rules here a little, I should > probably mention that my module is object oriented.) I've been calling > my package 'Server::MUServer'. > > After reading a bit, I can't tell if 'Server::' is the proper category, > though it feels right to me. Any other suggestions? > > Also, MUServer seems pretty dead wrong according to this section. I'm > guessing it should become a couple of complete words and lose its > "cute/acronym/jargon" qualities. Any suggestions as to what would be > better? I'd suggest something in the Net:: hierarchy. Perhaps Net::Telnet::Server, or something under Net::Daemon (though that has the pitfall of associating it with the Net::Daemon module, so maybe that's not such a good idea). MUServer is a little compact; something a little more clear would be a good idea. Whether or not a module is object-oriented usually has little to do with its name on CPAN. > Thanks for suffering through all this babble. Any pointers on my > questions or the CPAN process in general will be greatly appreciated. The CPAN modules mailing list archive is a good reference mostly for discussion on naming issues. A link to it should be listed in the document you're reading. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com -- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
