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.
