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

Rename Merkle links key from mlink to link #64

Merged
merged 2 commits into from
Feb 11, 2016

Conversation

mildred
Copy link
Contributor

@mildred mildred commented Jan 10, 2016

Merges to #37

Replaces mlink occurrences with link with a paragraph to explain how merkle-links are formed. Original comment and follow up

@jbenet jbenet added the backlog label Jan 10, 2016
@mildred mildred mentioned this pull request Jan 10, 2016
5 tasks
@jbenet
Copy link
Member

jbenet commented Jan 22, 2016

this LGTM. though do we want link or @link to signify importance, allow people to use link for other things (and \@link if they need to).

@mildred
Copy link
Contributor Author

mildred commented Jan 22, 2016

I didn't understand what you said about @link and what does it mean to have an important link.

@jbenet
Copy link
Member

jbenet commented Jan 24, 2016

Sorry, let me rephrase: do we want link or @link? the @ helps signify importance, as it is a clearly distinguished value, and we can do the directives + escaping. this also allows people to use the value link themselves without creating links accidentally.

(i myself am leaning towards directives + escaping)

@mildred
Copy link
Contributor Author

mildred commented Jan 25, 2016

If you want to add escaping, we can either let the application do the escaping on their own, or handle the escaping ourselves. Escaping implies that we will be able to provide the application with either the escaped (original) version, or the unescaped (with link information removed) objects. If the application wants to look at links, it will not be able to do so in the unescaped version the @link property will be removed). The application will also have to specify which version it wants and this may create confusion. "Which version should I get?"

I'd be tempted to say it doesn't matter if the application create links unknowingly. We'll just never use them. So let's use link, that's fine.

If we want to provide an easy way to avoid that, just use @links but let the application itself do the escaping. In any case, we probably don't want to bother with escaping in IPLD core. We'll just provide a library that the application would be free to use or not.

@jbenet
Copy link
Member

jbenet commented Jan 25, 2016

Very well thought out. thanks

If we want to provide an easy way to avoid that, just use @links but let the application itself do the escaping. In any case, we probably don't want to bother with escaping in IPLD core. We'll just provide a library that the application would be free to use or not.

Yep totally agreed here, i think this ^ is the right choice.

jbenet added a commit that referenced this pull request Feb 11, 2016
Rename Merkle links key from mlink to link
@jbenet jbenet merged commit 6e69d61 into ipfs:ipld-spec Feb 11, 2016
@jbenet jbenet removed the backlog label Feb 11, 2016
@jbenet
Copy link
Member

jbenet commented Feb 11, 2016

thanks @mildred

@daviddias daviddias added the IPLD label Mar 14, 2016
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

Successfully merging this pull request may close these issues.

3 participants