On Mon, Apr 02, 2001 at 09:43:34PM -0500, Brandon wrote:
> 1) First inserter dictates metadata of file forever.
> 2) Multiple versions of a file split popularity and double space usage.
> 3) Files don't contain their own metadata.
I think it's clear 1 doesn't work. 2 and 3 differ only in
that they have different ideas of what "the file" is. If metadata is
considered to be associated with the file, then in a way it is part of
the file, and thus must be considered when generating the CHK. That's
number 2. In 3 we don't have metadata, although it can be stored in a
separate file.
I think it's a lot easier to think about if you consider the
metadata to be part of the file data. The "problem" then with number
2 above would be that two files that differ only slightly are both
being stored. There's no way we can have the network say "these files
are pretty much the same thing, so I'm only going to keep one of
them." Metadata is part of the file, so if people put out two copies
that only differ in metadata, that's no more wasteful than putting out
multiple copies of the same file under different keys, and that
already happens.
If we decide to eliminate metadata, someone's going to devise
a file format that contains the data, and thus there would be metadata
in the file itself.
My personal opinion is that metadata is useful, but I'm not
sure if it needs to be implemented at a network protocol level. It's
nice, but it might be easier and more effienct to make it a
client-level spec. I guess it would kind of be like the difference
between HTTP 3xx codes and meta-refresh tags in the HTML files
themselves. It's convenient to have metadata, and it will remove the
need for some redundant client code, but I think it would be better to
have metadata not be tied to the protocol.
Jay Tamboli
--
Don't think of it as `gun control', think of it as `victim disarmament'. If we
make enough laws, we can all be criminals.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20010402/0cd8340f/attachment.pgp>