Yeah, I agree. This seems to be just adding restrictions that could hamper the effectiveness of third party applications.
On 27/10/06, bbackde at googlemail.com <bbackde at googlemail.com> wrote: > I heard that you want to make "CHK with filename" mandatory. What does > this mean ... > > I have to insert a file with URI=CHK@ and TargetFilename=abc. Then I > must request this file with URI=CHK at bla/abc? the CHK key itself is not > enough? > > The same file, but with different names, get another CHK key? > > What is the sense of this? You said it would be easier to find the > file in store, but why is this easier, the CHK is already unique? The > filename just adds another abstraction layer and you have to deal with > files of same name, but different content. Because of this you would > always have to use key+filename for lookups, why is'nt the key itself > enough for this? > > IMHO this concept leads to problems. I know that same files with > different names only have another key because the manifest is > different, the (hidden) datablocks itself have the same key. But how > should applications for file sharing and insert-on-demand work with > this concept? We share the file with a unique SHA identifier. If 2 > users have the same file, but with different names, this works well. > Now if there are the same files, but with different CHK keys because > the filename is different, the application would have to maintain a > list of all known CHK keys for a file with same SHA checksum, and it > would have to try to download one key after the other until a download > is successful. > > As you see, this concept adds more complexity to FCP2, with a > questionable benefit. Simple applications that count on this concept > would have problems later if there are alot of files from many users > floating around... they should respect that only the CHK key is the > URI for a file. This worked great on 0.5, everyone understand this and > its easier for all... > > Please don't make this mandatory. > > rgds, bback. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech >
