Comments (7)
Proposal: Simplicity over UX
Given that others are, hopefully at least, not using this format, we could just say that all paths must use link indices. We'll need to write a helper function to resolve named links.
from specs.
Proposal: Named xor Unnamed
If we require that all links in an object either be named or unnamed, we can redefine the structure to either have a map of link names to links or an array of unnamed links. The question is, do we ever mix named links with unnamed links?
from specs.
Re /Links/thing/Hash
, I don't believe this is possible in the current js-ipld-dag-pb. I supports /thing
and /Links/0/Hash
style. (I can't find a historical version that shows clearly that /Links/thing/Hash
was actually supported tbh).
So with them both supporting /thing
, an easy fix might to be to define that, plus the /Links/0/Hash
style as the way, then implement /Links/0/Hash
in he Go implementation, then they'd be unified and there will be peace in the world, no?
from specs.
So with them both supporting
/thing
, an easy fix might to be to define that, plus the/Links/0/Hash
style as the way, then implement/Links/0/Hash
in he Go implementation, then they'd be unified and there will be peace in the world, no?
The biggest issue here is that you then can't path through named links named "Links" or "Data".
Hence I propose (that's from a JS perspective as we have this clear distinction here, not sure about the Go side): IPLD only implements pathing on the structure aka /Links/<index>/Hash
. The named pathing only exists on the IPFS level.
By default the DAG API will only support the structured pathing (this would be a breaking change for go-ipfs). Though we could still allow /**ipfs**/Qmid…
paths in those APIs that would allow currently implemented way of pathing from go-ipfs.
There will be no way to combine the pathing of both ways. This way there won't be a naming conflict and you can even path through named linkes called "Links".
from specs.
Hence I propose (that's from a JS perspective as we have this clear distinction here, not sure about the Go side): IPLD only implements pathing on the structure aka /Links//Hash. The named pathing only exists on the IPFS level.
These 2 levels were once called resolvers and transformations and both were part of IPLD.
from specs.
The biggest issue here is that you then can't path through named links named "Links" or "Data".
seems to me that (a) this hasn't been a problem discovered by JS consumers and (b) if we're really the only consumer, via IPFS + UnixFSv1, then it doesn't really matter as long as IPFS doesn't need a link named Links
then it's just fine.
Wouldn't it be a more traumatic exercise to rip out /named
support from Go than to add /Links/x/named
as an optional - they're both technically breaking changes, but the latter is only breaking for links named Links
?
from specs.
seems to me that (a) this hasn't been a problem discovered by JS consumers and (b) if we're really the only consumer, via IPFS + UnixFSv1, then it doesn't really matter as long as IPFS doesn't need a link named
Links
then it's just fine.
If you add a directory called Links
into IPFS you will have a link with name Links
. This e.g. breaks the Explorer in the WebUI when you use js-ipfs. Browsing it as files and retrieving it via the CLI works, just just can't use named links via the DAG API.
/named
support in Go would still be there, just under the /ipfs
namespace. To me having no support for named links within IPLD sounds more correct based on what IPLD is like today.
from specs.
Related Issues (20)
- graphsync spec - clarify relationships between libp2p connections, streams, messages and requests HOT 1
- Self describing objects in the data model layer HOT 2
- Defining Any and its behaviors HOT 13
- Endianness in IPLD Codecs HOT 2
- CBOR: Data model serialization in Rust HOT 22
- Add more examples to Selector specs HOT 3
- Invariants for IPLD Codecs HOT 3
- Define "component specifier" HOT 1
- Spec for inline CID’s
- Request: Magic AMT HOT 2
- Data model - Integer as map key HOT 5
- Representation of Infinity and NaN in DAG-JSON HOT 11
- Confusion about envelope (and inline) representation of unions HOT 5
- Best practices for IEEE-754 non-fintite numbers (NaN, Infinity) HOT 1
- Documentation about "context" HOT 1
- codec: pathed link HOT 9
- Data Model claims (erroneously?) that DAG-CBOR rejects integers outside of 64 bit range HOT 1
- Is the String kind conceptually a series of bytes or characters? HOT 15
- Why is the reified form of IPLD Schemas "generally presented as JSON" instead of IPLD itself? HOT 1
- Register MIME type application/car with IANA HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from specs.