Possible conflict with content addressable schemes

[ross-spencer]

It might be something that can be worked out, but might also be something for docs.

You can imagine content addressable retrieval, e.g.

• wget https://aha-server/object/d41d8cd98f00b204e9800998ecf8427e -O myfile.txt

nb. for delivery, the file might need to be tarred and delivered for unpacking.

And you would download one version of this file that can be definitively pointed at through its checksum, enabling de-duplication and so on.

You can imagine metadata display and retrieval:

wget https://aha-server/metadata/d41d8cd98f00b204e9800998ecf8427e

{
  "xttars": {
   "k1": "v1",
   "k2": "v2"
   }
}

And in the xattrs implementation multiple files with this checksum might have different representations on disk, with different xattrs. It wouldn't be possible to retrieve this metadata without some other resolution method, e.g. hash = file_hash + xattrs_hash. So it might just require a consistent library to create xattrs_hash? or something else.

if the approach was taken on at all.

[pjotrek-b]

Indeed.

I also believe that "hashing-attributes" will make sense (for other use-cases as well).
Actually, having file_hash and xattr_hash should make it quite easy to maintain content-addressable schemes.

Because what I also tend to forget/overlook is, that considering xattrs as-common-as-filenames, dissolve "the one identifier" to use as filename/path limitation in general 😄
(I mean: by moving filename + path to become "just attributes" over time, the exclusiveness is resolved)

So, in your example wget https://aha-server/metadata/d41d8cd98f00b204e9800998ecf8427e:

What if https://aha-server/metadata/... can serve from different metadata sources?
(not just "THE path" and "THE filename" (as we're used to now)).
Therefore resolving, eg a combination of hashes (file_hash + xattr_hash) by a common-hash would work just alike.

[ross-spencer]

can serve from different metadata sources?

That doesn't seem difficult logic to enable resolution for someone attempting that -- could be very cool!

[pjotrek-b]

Actually, since you mentioned "https://", there's a server demon involved anyways:

So one could configure apache/nginx/etc to map the URL-parts dynamically to different "paths+filenames or attributes" for example. 😁