ML> ..but what limitations are you seeing that i haven't covered with
 ML> my tidbit?

I hope I am not mixing things up, but if You refer to the same proposal I
think of then the objection is that it is an untagged format. That will
unevitable lead into future problems and leftovers when modems are phased
out.

 ML> CSV databases have been used since the beginning of database
 ML> information storage... yes, their format may be "rigid" but that is
 ML> the same for all database formats...

A tagged format where the eppropriate fields are optional is not rigid.
When something is no longer needed, it just disappears without leaving any
placeholders to clogg up the list.

 ML> i don't believe that we should add any more info to the current
 ML> database style other than what is absolutely necessary...

There must be additons for the new connection channels and with separate
flags for them. F.ex. a node must have the possibility to be CM at IP, but
have a limited window for POTS. It must also be able to carry a Host or Hub
flag whithout POTS capabilities. That is a hard one to solve in the present
format, where no POTS states a _required_ Pvt-flag in the location where
Host/Hub should be.

 ML> why have to add field identifiers and then have to create "smart"
 ML> programs that have to be able to pick out the data they need no
 ML> matter what order it is in? it is much faster to read data
 ML> directly from where you know it is..

That is yesterday's way to do programming. Today we are moving in the
direction of datasets and DTD's, away from bits and bytes. The machines
does the work, not the man. Today we have gigahertz CPU's and
multiprocessing everywhere is just a few years away.

There was a time when CPU efficiency was needed, but those good old days
with their inspiring challenges are history and nostalgia now. I miss it
too, but we have to face reality. FidoNet is shrinking at a fearsome rate,
our only chance to survive is to keep up with the evolution.

 Best regards, //Haakan

--- MyPoint Windows 2.03xE