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