Re: Data table text I/O package?

["Randy Brukardt" <randy@rrsoftware.com>]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:m2k6ku8w2s.fsf@hugin.crs4.it...
> Randy Brukardt wrote:
>
> > I may be dense, but isn't this the purpose of XML? If so, why
> > reinvent the wheel?
>
> The purpose of XML is to be _the_ universal file format.
>
>  a) I don't want a universal file format.
>
>  b) I don't believe in a universal file format.
>
>  c) XML is (almost) less readable than a binary file my purposes.
>
>  d) I'm _not_ going to switch away from tabulator separated tables for
>     purposes, where tabulator separated tables are a sensible
>     representation of the data in textual form.
>
> > (I personally think XML is way overused, more because it *can* be
> > used than that it is worthwhile for the application. But this seems
> > to be exactly the application that it was designed for. You'll end
> > up with something like XML eventually anyway, why not start with
> > it?)
>
> I'm afraid you completely misunderstood my problem.  It is not a
> matter of a selecting a file format.  It is the matter of
> automagically generating code for reading and writing that file
> format.

Not at all. We like to say around here that you need to describe what your
needs are, because often the program you are trying to write isn't
appropriate for Ada. We usually use that for people trying to write C in
Ada, but it should apply to everyone. :-)

For program-to-program communication, there really are only two sensible
options. If both ends are under your control, then using a binary format
(with versioning and error detection if needed) is preferable, because it
has the least overhead and there is no need for data conversion. This
certainly is the only option with reasonable performance. And this is
usually the appropriate choice.

OTOH, if the performance of the connection isn't critical, then using a
well-known standard format that already has needed tools for it seems like
the best option. Even if you don't currently need to allow access by other
systems, you're leaving the door open for future programs outside your
system to use the data.

The cases that are neither of these and thus would make sense to use some
internal, non-portable text format are essentially non-existent.

Note that human readability of program-to-program data is a non-issue.
Indeed, it is a mistake to try to bring that into the equation, as it adds a
huge amount of overhead to the task. I've always used agile methods for
debugging such data: if, in fact, I need to examine such a data stream, I'm
write a program to display it. But I don't worry about that until/unless the
need arises. It often does not arise, and even when it does, it's often not
necessary to be able to display everything -- and it's often better to write
a monitor for an interesting condition than filling a disk with 10 GB of
text!

So, all in all, I think you're trying to solve the wrong problem (finding a
way to write a specific file format), rather than using an appropriate file
format for Ada programs (usually binary).

But, as a friend of mine likes to say, "do what you want, because you will
anyway!". :-)

                  Randy.