> 
> Why? How is it better to mix the data with the metadata?
> 
> Example message:
> Index
> Author=blah
> Title=blah
> Signature=blah
> Entry.1=freenet:CHK at q23123123123
> Entry.2=freenet:CHK at jkljklfg8ugf879gf87
> Entry.3=freenet:CHK at 548945894589045890
> Data
> <EOF>
Thats most certainly *not* what I was proposing.  I have no problems with
having the URIs be in the "Data" section of the message.  What I am saying
is that the line between the metadata and the data sections of a document
(as defined by Metadata-length and DataLength), should not be splitting
your message.

It should look like:

<----------------Metadata begins------------------------>
Author=blah
Title=blah
Signature=blah
Content-type=freenet/index
Data
freenet:CHK at q23123123123
freenet:CHK at jkljklfg8ugf879gf87
freenet:CHK at 548945894589045890
<---------------Data begins----------------------------->
<---------------Data ends------------------------------->

Ie, zero-length data segment.

> Compare to normal file:
> Author=blah
> Title=blah
> Signature=blah
> Content-type=image/gif
> Data
> <some gif data>
> [EOF]
Sure, but not complete enough:


<----------------Metadata begins------------------------>
Author=blah
Title=blah
Signature=blah
Content-type=image/gif
Data
<---------------Data begins----------------------------->
<some gif data>
<---------------Data ends------------------------------->
[EOF]

> 
> Why is the first way better than the second? The second is consistent with
> the normal way to represent a file, moves the freenet special file
> handling code into the same modules as the other file handling code which
> most clients will have to handle files of different types avoids the
> possibility of namespace collisions in the metadata section.
The first isn't what I'm proposing.

-------------- 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/20000821/e62f3130/attachment.pgp>

Reply via email to