Note: ObCircle subject: telnet implementation on CircleMUD (and the problem with accents). Alex wrote: > > > não consegui entender ao certo o que você realmente deseja rem relação ao > > remort. se possível, poste novamente sua dúvida, se for melhor pra você, > > poste em espanhol ou português mesmo. > Ok, it looks like ye ol' list admin is going to have to make a policy > statement about the use of foreign languages on the list and the > requesting of response in that language. > > Over the past couple of weeks there have been several posts in languages > other than English, and as a result, I've received notes from several > people (who shall remain nameless) asking about the list's policy on this. I'm in agreement with this new policy. I'm brazilian, and my first language is portuguese, but I'm feeling very uncomfortable reading a portuguese text in an english mailing list. These type of discussion denigrates the all the brazilian people. English was the language chose for a globalized world, and these posts show to the world that we (brazilian people) doesn't speak english et all. Unhappily, this is true. Less than 1% of the brazilian folks over 16 years call themselves english-speakers. I'm good on reading english. I work with computer maintenance and programming for 10 years, and all the existing documentation is firstly available in english. I have some little difficult to write english text, but I do my best, because I know how undesirable is reading something and not be able to understand. As said, CircleMUD was written in english, and all documentation is available in english. I think that everyone that want to implement a Circle-based MUD, should at least speak english. > In short, some people are getting frustrated that this list is for the > discussion of CircleMUD topics for _everyone_ on the list, but that (for > example) in the note above, the question was asked in Portugese and > according to AltaVista, it is asking for a response in Spanish or > Portugese. You are right. Only a side note: The same boy sent me an e-mail some weeks ago, using a very poor english (note that we are both brazilians), saying that he was russian (!!!) and asking for help in a way to make CircleMUD accept accents (extended ASCII characters). I discovered that he was brazilian through his IP address. This lie made me very angry. And now, I open my mailbox and got a message from him in portuguese, on this mailing list. Ok, ok, I don't want to spam the list with our personal differences. It was just a side note. /* As stated on the CircleMUD mailing list FAQ */ static const char *ObCircle = ... Saying about foreign languages, and some posts on the last 3 weeks about accents, I should give my word. I have successfully made CircleMUD accept extended ASCII characters. The biggest problem is, when you open the way to ASCII chars over 0x7F (127), you are open the way to a bit of protocol-specific trash too. This is because TELNET uses the characters 0xF0 (240) to 0xFF (255). CircleMUD definitely is not a telnet daemon. Everything that passes through process_input() is treated as user input. The solution (that was what I have made on VitaliaMUD), is to implement the telnet protocol on the source of CircleMUD. Unhappily, it is impossible to extract a patch of that from my MUD. I have made a layer-based communication system on my MUD. The files comm.c and comm.h simply doesn't exists on VitaliaMUD. They was entirely rebuilt as a couple of other files (main.c, socket.c, descriptor.c, telnet.c). The "layers" that I have arranged all this stuff are: 1. Socket layer: Actually, there is only one socket layer implementation: TCP. It only reads and writes to sockets and maintains buffers of the input and output. 2. Handler layer: Three handler layers implementation available: telnet, ssh and http. Actually, only telnet is usable, the other two are experimental. All the telnet protocol stuff is handled here. It reads every input got from the socket layer and interpret if needed. 3. Descriptor layer: Manages the formated input and output. Has links to the editor (string_write() to CircleMUD speakers), color processing, history handling, etc. It knows if the player needs to read what it is typing (echo on and off), and sends the correct messages to the handler layer when needed. This splits the input in "command lines", and send to the next layer. 4. Interpreter layer: There are many interpreters implemented, one for each occasion. One for character creation, other for menu, other for normal game input, other for editor, etc... Only the interpreter layer access the Character object directely (struct char_data to CircleMUD speakers). It call the commands, that are able to change from one interpreter to another (like "quit", that changes from the game_interpreter to the menu_interpreter). All this implementation works good for me. But it is not ready for releasing. There are many quirks to be fixed. I think that CircleMUD should adopt these structure, or something like that. From my own experience: this makes the code MUCH MORE clean. It is like a workgroup: each man do only his own work, without overlapping the other. All men working together creates the final product. The listen sockets works in a similar way. With 3 layers: Server, ListenPort and AcceptHdl. The server can have many listen-ports as needed, each listenport is assigned to an accept-handler, that creates the socket, the descriptor, assign them to the telnet_handler and the login_interpreter. One of my ideas is to create a SSH daemon builtin on the MUD. Then, when the SSH handler is done, the only thing I will need to do is to open another port on configuration files, and assign to a new accept-handler. Somewhat complicated, yes, I know. But I feel my implementation of CircleMUD is going to be one of the most robust MUD implementation. Regards, Juliano -- A Bugless Program is an Abstract Theoretical Concept. -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST