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
I guess it's sufficiently low-level to validate the existence of a state
variable for encrypted and/or compressed. Then again, I don't know. 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:
class SocketFilter // An interface/protocol.
{
public:
SocketFilter();
SocketFilter(const SocketFilter&);
virtual ~SocketFilter() = 0;
virtual string ParseInput(const BaseSocket&, const string&);
virtual string ParseOutput(const BaseSocket&, const string&);
};
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. As far as the higher level socket functions should know,
there are no filters. The final data after being passed through all the
socket filters should appear, for all intents and purposes, to have been
the actual I/O, regardless if it's completely different. For instance, I
might choose to filter all M's into V's. The command interpreter, etc.,
should only know about the post-filtered version, and be completely
unaware that any filtering at all has ever ocurred on any of its input.
(This is important to establish a simple, stable, and secure contract
between filters and sockets. It also encourages people to write the code
all in the filter, rather than writing filter-specific code in the socket
class.)
> Actually, STL ("map" is neat) isn't looking too bad recently so I'm leaning
> toward something C++.
hash_map<> is keen. It's an extension to the STL. But it's not terribly
difficult to provide an implementation.
> My thoughts were:
>
> - 3.0 betas
> - 3.1 First CircleMUD 3.x stable release.
> / 4.0 Circle^2 (or Circle^3, depending on pun)
> \ 3.[2-9] Concurrent with 4.0 for some post-3.1 cleanups.
I think:
3.0 - betas
3.1 - First CircleMUD 3 stable release
3.1.x - Continuation of 3.1 family.
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
So after 3.0/3.1, we can use the Linux versioning scheme. For people who
don't know, yet, the reason for doing this rather than having a stable 3.0
and making 3.1 a development release is to eliminate confusion between all
of the beta patch-levels and the non-beta. The advantage of the Linux
versioning scheme is that it's instantly possible to tell whether any
version is or isn't stable and how far along it is. I would fully expect
to see something like 3.9.17 before we ever saw 4.0. Once 4.0 went
stable, we'd create a 4.1 branch, take a break, and handle bug-fixes by
integrating them into 4.0.x releases as well as the 4.1.x development
releases.
> Not that I'm doing anything more than in-head design until 3.1 is finished.
Same.
> 3.1 vision:
> some more bugs (see bugs.circlemud.org)
> documentation (see Jeremy, hoarder of old documents) :)
> yank olc.c or continue our denial of its existence.
> 3.[2-9] vision:
> OLC
> ASCII data files (players, objects, boards, mail, etc.)
> code-stuff reorganization (like db.c's uselessness post-boot)
Reorganizing db.c could take two alternate paths.
Approach 1: db.c as Database Parser Routines
This approach would have the creation of two new files, structs.c and
file.c. structs.c would handle structure allocation and manipulation
functions (e.g., clear_char(), create_char()); file.c would handle all
file I/O (e.g., get_line(), fread_string()). It would also be
be acceptable, though not as clean, to move the bulk of these routines
to utils.c.
Justification: this leaves db.c as just the routines for parsing the
database format, rather than everything even remotely associated with
the game's database.
Approach 2: Split db.c On Type
Rather than have db.c as a parser, it would take on more the role of
file.c from Approach 1. Structure handling and actual record parsing
of the database would be performed by db.XXX.c modules, where XXX is
the abbreviated name of the type. E.g., db.wld.c for world files and
db.zon.c for zone files.
Justification: A divison based upon visible type rather than function.
This is more object-oriented (not the programming, the actual layout
of the files), concerned more with what the data is than what the
functions are doing to it.
I don't know what's better. I don't know if either is good.
-dak: thinks CircleMUD Community Request for Comments would be useful.
--
+---------------------------------------------------------------+
| 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