On Tue, 16 Jan 2001, Daniel A. Koepke wrote: >On Tue, 16 Jan 2001, George Greer wrote: > >> I was thinking of the socket class possibilities being: >> >> encrypted | compressed (think bit flag state possibilities) >> TCP or Unix domain socket > >It seems to me that it'd be better to implement encryption and >compression as some sort of filter that the socket writes/reads through: Exactly what I was thinking. >Then maintain a list<> of socket filters on the connection socket, I >guess, and pass the I/O through them. The filters should work >transparently. [...] Right. You have the idea. > 3.0 - betas > 3.1 - First CircleMUD 3 stable release > 3.1.x - Continuation of 3.1 family. Let's hold off on the x.y.z syntax for awhile to remove the beta taste from our mouthes. > 3.[2,4,6,8] - Reserved for stable releases in the 3.x family. > 3.[3,5,7] - Reserved for development releases in the 3.x family. > 3.9.x - 4.0 beta family > 4.0 - First stable release of 4.0 I wouldn't be so rigid as saying 3.9.x must go to 4.0. I'm thinking 4.0 would be different enough to start over. I want to use lex/yacc for parsing world/mob/obj/shop/zone files, for example. >So after 3.0/3.1, we can use the Linux versioning scheme. [...] As mentioned above, I'd rather wait a bit. We don't want 3.1.5 associated like 3.0bpl15 was. >Approach 1: db.c as Database Parser Routines >Approach 2: Split db.c On Type Actually, I just meant making the parse_* functions usuable after the MUD has booted. Then zones could be dynamically loaded for either memory concerns or offline editor updates. -- George Greer | If it's about the CircleMUD mailing list, greerga@circlemud.org | mail owner-circle@post.queensu.ca instead. -- +---------------------------------------------------------------+ | 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/03/01 PST