On Mon, Aug 21, 2000 at 10:07:23PM -0500, Scott G. Miller wrote: > > > > No possible namespace collisions between metadata properties and data > > properties. If you combine them then you have assume that the authors of > > metadata schemas and the authors of special Freenet file schemas will > > never pick the same name for a field. > *What* are you *talking about*? This has nothing at all to do with > freenet-special data. Freenet-special messages are a rigorously defined > few messages for very very very necessary things like redirects. Anything > outside of what we spec isn't freenet-special, and should be treated as > normal data. > > > Consistency. Special Freenet files can be handled exactly like > > normal files. No special coding. No additional design effort. You just > > code the modules for handling files of this type, just like you code the > > modules for handling gifs, mp3s, and html files. > I don't think thats a reason to make it hard to parse a freenet-special > message.
Okay, to avoid all this semantic argument, I hearby proclaim what was formerly known as metadata is named control section from this point forward and what was formerly known as data is named data section from this point forward. The control section contains not just public metadata but also all control information such as redirects and expirations. > > I think that the difference in opinion might be caused by the way that we > > are viewing the special Freenet files. I think that maybe you and Scott > > are looking at them as control messages. So a redirect is a command to the > > the client to fetch another key. > YES. And or give the client some information on which it must act to do > anything useful. And all non-file data information should be placed in the control section. (Read above if you don't understand what I mean by control section.) > > > > Similarly, an index file is a normal file. The default handler for most > > clients for files of type freenet/index would display the index in a > > clickable form to the user. For client authors just starting out, that > > haven't written this module yet, they could just install the default text > > file viewer module in its place and the index file would be shown to the > > user, at which point the user could type in a desired key from the > list. > No. This is not a freenet-special file. Its an app-specific > thing. Redirects are absolutely necessary because we aren't allowing data > to be stored in KSKs or SVKs. What he said about indices is correct. Redirection does however belong in the control section. Of course, an index format already exists (fnindex), which places information entirely in the data section (including stuff that I might move to the control section such as metadata). > > The benefits of treating special Freenet files as normal files instead of > > as control messages are as follows: > > > > Consistency, as above. The special file handlers are on the same > > level as the other file handlers. There is not an extra layer specially > > made to handle special Freenet files. There is no additional code or > > design or documentation necessary. It's a single consistent interface. It > > will be easier to program and customize clients. > There's no need for this. This is perfectly possible under my system as > well, so I don't see why you're fighting it. Actually, putting the redirect data in the data section would be easier to parse, but FNP is extremely easy to parse, so it really doesn't make much of a difference. > > Integration with non-Freenet tools. Since Freenet URIs and indices > > are just normal files with mime types like any other file, it will be easy > > to integrate such files with any mime-aware system. In a properly > > configured system, you should be able to fetch an index, save it to disk, > > e-mail it to a friend, and when they open it it will launch their Freenet > > client and show them the index. > Yeah, and? Still not making any relevant points. > > > To me, having files in the same format as messages and have special > > Freenet files be handled just like normal files is natural. What are the > > benefits of doing it the other way? > The sole advantage of my system (besides having all your advantages as > well) is that its easy to detect when you have a freenet-special control > message. Of course, detection will not be necessary because all KSKs and SVKs will be control messages. However, if we allow the use of the data section for KSKs and SVKs, it *will* be abused (which defeats the purpose of requiring KSKs and SVKs to be redirects only). -- Travis Bemann Sendmail is still screwed up on my box. My email address is really bemann at execpc.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 3315 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000821/567f7ff9/attachment.pgp>
