Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attempts on IPLD #90

Closed
nicola opened this issue Apr 2, 2016 · 9 comments
Closed

Attempts on IPLD #90

nicola opened this issue Apr 2, 2016 · 9 comments

Comments

@nicola
Copy link
Member

nicola commented Apr 2, 2016

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
Copy link
Member

davidar commented Apr 2, 2016

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

@nicola
Copy link
Member Author

nicola commented Apr 2, 2016

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 /

@ghost
Copy link

ghost commented Apr 2, 2016

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 [email protected]
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
Copy link
Member Author

nicola commented Apr 2, 2016

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
Copy link
Member Author

nicola commented Apr 2, 2016

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

@daviddias
Copy link
Member

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
Copy link
Member Author

nicola commented Apr 3, 2016

@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
Copy link
Member

@nicola I think we can close this?

@nicola
Copy link
Member Author

nicola commented Jun 13, 2016

This has been discussed and lead eventually to #97

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants