> > What I'd like to do (and have code started for) is state in the protocol > > that documents with metadata present but zero-length data fields are > > considered Freenet specific control messages. > > I'm not quite sure what you mean, but if you mean client-side controls > like redirects then it's not a protocol issue (being client-side). No. I meant that when a document has a metadata section present, but no data present, then a certain metadata encoding is *mandatory*. Ie FNP. Then the client also knows that the metadata that is present is Official-Freenet-MetaDocument data, and should behave in a predictable manner.
> But yeah, if that's what you mean then that seems sensible except that > it'd prefer that it was explicit that it was a control file instead of > implicit by the length. I want a big HI I'M A CONTROL FILE label stamped > across it. Which is why I think it would be good to have a field in the > message (say, Content-Type=freenet/control) and then put the control file > in the trailing field. Another reason to put the control file in the > trailing field is in case you want to have non-fieldlike > information. Putting in a field or two works fine for redirects, but gets > unwieldy with things like indices. Oh hell yeah. The contents of the metadata would still be pretty blatheringly obvious, ie: Redirect Redirect-to=freenet:CHK at klasdfadsfldsfdfjsdf or Multipart Part-count=10 Part-1=freenet:CHK at asdlfldsfhsadfraewf Part-2=freenet:CHK at alsdfhjsdfadfkdsfj ..etc -------------- 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/20000818/f56559a8/attachment.pgp>
