> Which was my point. Would you stop insisting that the URL can't be in the
> "metadata part" if we called it the "Twinkletops part"?
We can call then A and B if you like. My point is that there are two types
of information. One is about the file itself. It is non-essential. It is
used to determine if this is the file you want, but isn't necessary
otherwise. We've been calling this metadata. It has things like the author
of the file, a signature, etc..
The second type is that which is necessary to the file, what we've been
calling data. This is what will be saved to disk, sent to an external
viewer, etc..
There are several reasons why you want to separate these two types of
information. Having two sections isn't the only way, of course. You could
have metadata.x and data.x properties. Splitting into two sections is just
conventient because you can give a file the same format as a message
(therefore code reuse and consistency and you don't have to invent
anything new) and I think it looks less cluttered than using
namespaces.
The reasons for separating metadata from data even for the special Freenet
files are as follows:
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.
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 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.
I look at special Freenet files are normal files which have a special
context in Freenet. There isn't a redirect, per se, but rather the file
which a KSK points to can be a file of type freenet/URI or some such. It
contains a URI. The default handler installed for most clients for that
type would fetch the item with the given URI.
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.
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.
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.
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?
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
