Attempts on IPLD

[nicola]

Following up the conversation that we had a couple of weeks ago, I took some time (with the help of @Stebalien) today and wrote down a path scheme that would keep the single /:

https://github.com/nicola/merkle-paths

I will put up a very simple implementation some time soon, I want to hear feedbacks now!
Also, I added some examples, amongst those an attempt on how to do cyclic graphs using relative paths

/cc @jbenet @noffle @diasdavid @mildred

[davidar]

Isn't this the same as previous suggestions but using # instead of . or @?

[nicola]

Hy @davidar, I haven't read ALL the ipld threads yet. I think it is a slight modification of that, . is only used for properties that a parent assigns to a link. So, local properties are still traversed with /

Overall, looks good. But I wonder why have the scheme introduce ordinal
numbering in the namespace? (viz."0" in // /hash/friends/0 and //
/hash/friends/0/name from first example).

I understand that it is convenient to be able to address the names based on
their ordinal position within the set of path elements (I presume that's
what "0" represents above), but my concern with this is:
a) the naming schema must now define a function to map name -> position,
and ofcourse its inverse. Which implies a particular ordering of names
(lexicographic ordering?). What happens for different character sets? Such
a function must be specified completely for consistent and therefore useful
behavior.
b) how does this co-exist with names that appear themselves as numbers?
What if I wanted a path element to be named "0", perhaps because I wanted
to imply my own ordering? Obviously one of the two must take precedence
since the same identifier "0" means one thing under the ordinal position
scheme and something else when interpreted as a user defined name. To have
the former take precedence means the potential namespace is restricted
(some path components -e.g. "/0/" - are invalid). Whereas to have the
later take precedence means a potentially confusing namespace, as "/5"
might be a name whereas "/0" is the first element in the set.

IMHO I think its best not to map the ordinal position of path element's
into the path namespace. But allow the namespace to be entirely
user-defined (treat names as just labels) with no special interpretation -
no keywords, no ordinal numbering. There may still be convention adopted
around the names (e.g. the Unix Filesystem Hierarchy Standard) but that
would not be something hard-coded in the scheme.

I agree that such ordinal enumeration of path elements is useful, but might
best be provided by the API using programming language constructs - e.g. an
iterator.

• Brenton

On Fri, Apr 1, 2016 at 8:08 PM, Nicola Greco notifications@github.com
wrote:

Following up the conversation that we had a couple of weeks ago, I took
some time (with the help of @Stebalien https://github.com/stebalien)
today and wrote down a path scheme that would keep the single /:

https://github.com/nicola/merkle-paths

I will put up a very simple implementation some time soon, I want to hear
feedbacks now!
Also, I added some examples on how to do cyclic graphs using relative paths

/cc @jbenet https://github.com/jbenet @noffle
https://github.com/noffle @diasdavid https://github.com/diasdavid

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#90

[nicola]

that is equivalent to, since array indexes can be mapped to a map where keys are the array indexes

{
  friends: [{
    name: "Adam"
  }]
}

{
  friends: { 0: {
    name: "Adam"
  }}
}

[nicola]

Update: I added some notes on a possible way to encode it to have a cheaper link following, let me know

[daviddias]

Using # will conflict with browser local links (<div id='someId'></div> will be accessible with url/somePath#someId

Not sure if I understand the motivation behind "HTTPLinks". You can also have mutable links with Self Certified Links (e.g IPNS).

Another question is: how would you guarantee that the arrays on the objects will keep the order on their JSON representation?

[nicola]

@diasdavid the # is just a divisor, it could be anything, it is a way to show that you can't access that property via /, unless you other look it up from the parent or with a different divisor.

MerkleLink and HTTPLink are just tags in my case and show how you could also have link that are non merkle. (Although my focus is IPFS-related) I was thinking of generalizing this to any type of urn/url/iri name.

Is your question about supporting the array? In my case, I just map the array index to a map where the key is the original index. (I might not have understood the question or haven't considered the problem)

[dignifiedquire]

@nicola I think we can close this?

[nicola]

This has been discussed and lead eventually to #97