and what's abour using EBML (http://ebml.sourceforge.net/ or
http://matroska.org/) instead of XML for file listing ?
and what's abour using EBML (http://ebml.sourceforge.net/ or
http://matroska.org/) instead of XML for file listing ?
I don't know why but I think someone will tell us it is not natively available under windoz.
I don't know why but I think someone will tell us it is not natively available
under windoz.
Why _not_ use XML?
> Why _not_ use XML?But still very compressible as most data is text (filenames)...and since
Much smaller because it's a binary format.
If we really need small filelist, we can use EBML + Compression.Yes, but the two compressed file lists will probably end up at similar size
> Why _not_ use XML?
Much smaller because it's a binary format.
This looks a lot like a previous discussion where we have to choose between a binary or a text protocol :)
> XML has the extra advantage of being a standard with several
> implementations on different platforms and in different languages which
> has to count for something. There are plenty BZ2 and GZIP implementations
> available aswell.
You are fully right, EBML is probably to recent to have a port everywhere.
Yes, but both BZ2 and GZIP are very good at working with repetitive
strings. I haven't looked much at the EBML, but my impression is that the
XML file will be much more compressable than the EBML, and if the XML is
larger than the EBML uncompressed is completely irrelevant.
XML has the extra advantage of being a standard with several
implementations on different platforms and in different languages which has
to count for something. There are plenty BZ2 and GZIP implementations
available aswell.
> > Why _not_ use XML?
>
> Much smaller because it's a binary format.
But still very compressible as most data is text (filenames)...and since
we'll be compressing it anyway, the size really doesn't matter as XML
compresses away easily...
/J
Yes, but with EBML we don't need to compress the data.
We can exchange the datas directly.
On Friday, January 23, 2004, 10:28:47, Yves BLUSSEAU wrote:
> Yes, but with EBML we don't need to compress the data.
> We can exchange the datas directly.
Let's see: my filelist is 369kB uncompressed. If we start using (EB|X)ML, I
imagine it'll only become bigger, due to added data (actually, if it'd only
carry the same information as is in the list now [filenames and sizes],
EBML might be a bit smaller). No matter which compression you use, the
filelist will become smaller, and that is the whole point - have as small
filelists as possible, which carry as much data as possible. It's always
faster to upload 85kB than 369kB. (This reminds me, did anybody look into
7Z for compression :)
--
begin .sig
< Jernej Simoncic >< http://deepthought.ena.si/ >
It ain't necessarily so.
-- Gershwin's Law
end
Yes, but with EBML we don't need to compress the data.
We can exchange the datas directly.
Let's see: my filelist is 369kB uncompressed. If we start using (EB|X)ML,I
imagine it'll only become bigger, due to added data (actually, if it'donly
carry the same information as is in the list now [filenames and sizes],EBML
might be a bit smaller). No matter which compression you use, the filelist
will become smaller, and that is the whole point - have as small filelists
as possible, which carry as much data as possible. It's always faster to
upload 85kB than 369kB. (This reminds me, did anybody look into 7Z for
compression :)