The Message I Accidentally Sent To Mike Champion Rather Than The List

[Alaric Snell <alaric@alaric-snell.com>]

Quoting Michael Champion <mike.champion@softwareag-usa.com>:
> > it's trivial to write something that compresses better
>
> Undoubtably true, but will the difference make a difference? Can you
> make a
> business
> case that someone will get more happy users for the actual product by
> writing
> something
> that compresses x% better than an off-the-shelf generic technology?
We had that discussion before, I was just refuting a statement :-)
> The
> success of the HTTP/HTML is probably due to the economy gained by
> ignoring
> many of the nasty problems that previous hypertext proposals handled
> "better".
> And the he bankruptcy courts are clogged with companies that had a
> "better"
> solution to a problem that people didn't care about strongly enough to
> actually pay to have solved. "Worse is better" may be lousy technology,
> but
> tends to be good business, and engineering is all about making
> appropriate
> tradeoffs between the two.
I'd phrase that as "there is more to a system than pleasing the programmers"
Commercial factors matter too, as does making the result provide meaningful
features to the users. However, XML is very low level; users will not care
about the format of the data files unless they're power users, or the data
format's output are significantly larger than they have to be and cause data

storage requirements / processing times to rise beyond acceptable limits.
The
results of a particularly nice data representation toolkit in giving
developers
more time to work on other things may indirectly affect the users, of
course.
But when people tell me that text formats are more popular than binary
formats
due to some idea of increased ease of implementation, I suggest they
implement
a (validating!) XML parser and take a look at the binary executables,
images,
zipfiles, and so on in their binary filesystems :-)
Even in the text-manipulation-tool-rich Unix world, application data files
are
as often binary as textual. Gnucash has moved over to a gzipped-XML format,
but
there have been some complaints coming up now about load times; last time
this
was discussed it was decided that the XML format would probably have to go
at
some point in the future, to be replaced by something seekable; you
shouldn't
need the whole file in memory.
Gzipped XML is interesting. They are often smaller than the equivelant
binary
encoding, but the equivelant binary encoding isn't representing the "body
text"
any differently to the XML (unless it's really an integer or something like
that written out in decimal); people should compare gzipped XML against the
gzipped binary file, not ungzipped binary against gzipped XML. Duh.
The deflate algorithm used in gzip is incredibly complex to understand and
is
nontrivial to implement. It requires special tools to access. gzipped files
are
not human readable.
Does everyone here actually know how deflate works? I can post a summary if
you're interested in what you're actually using as part of your efficient,
simple, understandable-by-anyone data interchange format :-)

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software