-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, I'm new. I've looked at the FAQ. I've done a brief scan of the mailing
list archives (a search function, a-la htdig, would be a BIG help here,
folks), and I'm still not seeing a clear reason why freenet needs catalogs.
What are people going to do? Download a catalog, grep the catalog for a
keyword, and then submit a fetch on the keyword. There may be some people
who will browse the catalog like a menu, but this will constitute a sparse
minority of the total users.
Freenet is getting away from the proven interface of keyword submissions;
Gnutella, Napster, Google... the paradigm is one of sending out a request for
keywords and getting a list of possible matches in return.
The only thing hindering the implementation of a scheme like this is the
combination of factors:
1) Freenet needs to have keywords be obfuscated.
2) Freenet stores keys as one long string, hashed.
(1) can be maintained, but (2) is just a limitation. Freenet keys should be
broken up, hashed individually, and stored as a variable-length array of
hashes.
EG:
INSERT
1) User inserts data into the freenet.
2) The client takes the supplied key, and breaks it up based on parsing rule;
IE, each word is separated by a space or a "/"
3) The client creates a 32 bit (or whatever) hash of each word, and appends
them together, inserting the resulting number into the system as the key for
the data.
SEARCH
1) User submits a search request
2) Client takes request, generating hashes on the keywords supplied
3) Client submits resulting concatenation into the system as a search request
4) Each contacted Server takes the number and compares the hashes to the list
of hashes that the Server holds, returning matches to the client, along with
file size
5) Client receives hashes from server, and displays matches with
corresponding file sizes to User in order of number of matched hashes.
6) User selects files to download.
The file size is an important characteristic, and tells the user much about
the file. For example, most people know that MP3 files are going to be
around 5MB, and that text documents are going to be much smaller.
The advantages of this system are numerous:
1) Data often falls into more than one category; therefore, a CAD file
describing an Andrew Loyd Right building might be filed (under the old
system) as cad/architecture/houses, or it might be filed under
art/buildings/design, or ... I've always had difficulty accepting the
limitations of organizing data by categories in a hierarchy, since these
hierarchies almost never allow for the fact that data often falls into
multiple categories. This system removes the hierarchy limitation.
2) Keys remain obsifuscated
3) There is no dependancy on posted catalogs
4) The user interface is more simple than with catalogs
5) The interface is orthogonal with other interfaces users are used to
(Napster, Yahoo)
6) The system is efficient
If this design has been discussed before and rejected, what are the reasons
for the rejection?
Thanks.
=== SER Deutsch|Esperanto|Francaise|Linux|Java|Aikido|Dirigibles|GPG
=== http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737
Evil originates when people begin viewing other people as objects.
-- Granny Weatherwax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE63cf8P0KxygnleI8RAnh0AKDKvLWfqB9mOJtoMxNJkurzOzPeJACgwTjj
87Eh2spHiyAvjrR+I90UhUw=
=7l/6
-----END PGP SIGNATURE-----
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
