Separate filesystem merkle-path from IPLD merkle-path #60
Conversation
mildred
force-pushed
the
ipld-spec-linkprop
branch
from
1eccaeb
to
9f3acf2
Compare
|
|
||
| Path elements are suffixed by either `.link` to access the link properties or by `.object` to dereference the _merkle-link_. if no suffix is present, the _merkle-link_ is dereferenced (to be compatible with _filesystem merkle-paths_ in most cases) | ||
|
|
||
| **FIXME**: perhaps use different suffixes so we are less likely to have ambiguities. Using a character that is denied by Windows would be a good idea since those are less likely to be present in filenames. For most cases, this would make _IPLD merkle-paths_ a superset of _filesystem merkle-paths_. For example we could use `?link` and `?object` |
There was a problem hiding this comment.
being able to access link properties includes making it possible to do so via HTTP
There was a problem hiding this comment.
I did not intend to use the ? character to enable a special HTTP feature, but we could imagine it without problem. That's a separate issue for me.
mildred
force-pushed
the
ipld-spec-linkprop
branch
from
8b027ac
to
c081ae1
Compare
|
Commit Talk about escaping keys in merkle-paths is taken from PR #59 and commit Consideration about key escaping is additional remarks for IPLD merkle-paths in case we use escaping. |
|
What path syntax do you prefer?
Perhaps more people should express their opinions on those. As for me, I prefer the first solution (that's why I put it first). I generally use prefixes and suffixes when I need to encode things in file names. |
|
Also, is there any objection to having two different path syntaxes? One specific for filesystems and one for accessing properties. |
| An _IPLD merkle-path_ is an extension of a _filesystem merkle-path_ which uses a special syntax to access link properties. **[In case we use escaping in protobuf IPLD format** Except that key escaping is not performed when looking up items in the IPLD objects. This allow accessing reserved keys using _IPLD merkle-paths_ that are not accessible in filesystems.**]** | ||
|
|
||
|
|
||
| Path elements are suffixed by either `.link` to access the link properties or by `.object` to dereference the _merkle-link_. if no suffix is present, the _merkle-link_ is dereferenced (to be compatible with _filesystem merkle-paths_ in most cases) |
There was a problem hiding this comment.
Update: Ignore me, it's too early, this is pretty much the second solution I just realized
Disclaimer: I'm late to this party so if I missed something please excuse me
I do very much like the notion of this solution, but .link and .object seem quite verbose to me, why not use two separators like # and . instead, so the example paths would be transformed to the ones you can see below
- the path
/ipfs/QmCCC...000/stuff/foo#modeyields0755 - the path
/ipfs/QmCCC...000/stuff/foo/other/cat#modedoes not exists becauseotherdoes not have acatobject, only acat.link - the path
/ipfs/QmCCC...000/stuff/foo/other/cat.link.modeyields0644 - the path
/ipfs/QmCCC...000/stuff/foo.other/cat#yields objectQmCCC...222
This would make the paths a little less verbose for me. I do see that conflicts with things like cat.link in the second object are still an issue, so it might make sense to use different separators, though . feels quite natural for the object selection to me.
|
I prefer the second solution (
So something like |
|
I have no strong opinions on the matter, but I just feel that @jbenet, do you have a preference for one syntax or the other ? |
|
@mildred still mulling over. I'm re-confronting this once more. quick note:
We could do this. my intuition is that it will be quite confusing for people (when to use each), so if we do go down this path we need to explain the clear need for them, have them be distinct enough. looking at the simplicity of JSON is a good reminder of how simple formats win. It is also possible to allocate a prefix, like with |
You're right, we don't need to have different kind of merkle-paths if we do not intend to use them for filesystems for HTTP gateways. If as you say (and I have forgotten) the unixfs paths is already different from merkle-paths, we can decide for just one kind of merkle-paths: what I called IPLD merkle-paths. |
|
Probably obsolete in favor of #62 |
This is an attempt at solving "Accessing link properties problem (important issue to resolve)" from PR #37
TODO items:
.objectvs?objectvs:object) or which special character to use (.vs|)I proposed two solutions, and one with a variant, corresponding to these three ideas
Introductions to the changes:
What is a merkle-path?
A merkle-path is a unix-style path (e.g.
/a/b/c/d) which initially dereferences through a merkle-link and allows access of elements of the referenced node and other nodes transitively.There is no single merkle-path, but there are two:
When you use a merkle path, make sure of which one you use. Command line tools are encouraged to allow switching between the two flavors using a switch.