This list supports:

This list supports:
	copy construction,
	"virtual" destruction,
	streaming,
	comparison (equal comparison currently supported).

With the "object oriented" nature of the list, nodes, and records; it is
easily concievable that sorted lists and hash tables could be implemented
with little extra effort.

Philosophical point:

I am sure there is room for improvement with this design.  I am
submitting this as a generic doubly linked list recomendation for IJB.
Whatever the "collective" decides is fine with me.

This implementation uses the "naming space" of gen_list, derived_rec,
construct, copy construct, stream, destruct, etc...  These are open to
argument.  I just used what was familiar to me and others in the "OO"
community.  If these need changed to be adopted ... "so be it".

Implementation point:

I assume this is too late for a "3.0" release.  As I work for an
airline, the whole past summer has been hectic (not to mention the
last 4 months); but things have begun to settle down and I am
following the IJB lists a bit more closely.  And I would like to say
"HOLY CRAP!" .. you guys have accompolished a lot!  Way to go.

But, the adoption of a better linked list package should at least be
high on the next release list (if not the current one).  If you choose
this submission or not, so be it.  But as a "data structure" man, I
think IJB's linked lists need addressing.

List/Enlist note:

I have noticed the list.c file.  If this generic list is adopted, I
think all existing functionallity could be duplicated with the
"copy_contruct", "equal", and "destruct" `virtuals'.  This would also
eliminate and/or enhance the other manually maintained lists in IJB.

Debug note:

Since the generic list defined a "stream" virtual, it could be programmed
that the list could print itself whenever a FATAL error occurs.  A user (or
programmer) could read the list and hopefully determine the cause of the
abend.

Potential note:

Think of the possibilites of a linked list, sorted list, and/or a hash
list.  Think of a request to a web site that has been referenced
before.  If a hash list keep track of all block requests and regexp
change commands, then a site could be blocked and/or modified without
ever consulting the actions lists again.  What a speed up!

What if some of the current lists were kept in sorted lists?  Then a
search for a particular record could be a binary search instead of a
linear search.

The actions file(s) and regexp files(s) could be inserted into the
list from front to back order (or visa versa) and the processing would
take place in actual file order (which is more natural); rather than
in reverse order (as it is today).

Thank you for you time and attention to this contribution.  If it is
"blessed" by the group, I am available to give time to integrating
this into IJB.

Let me know what y'all think about this package.

--
Rodney