1. 23 Feb, 2018 1 commit
  2. 06 Dec, 2017 1 commit
  3. 06 Oct, 2016 1 commit
  4. 30 Jan, 2016 1 commit
  5. 20 May, 2015 1 commit
    • W. Trevor King's avatar
      namesys: Add recursive resolution · 3ead2443
      W. Trevor King authored
      This allows direct access to the earlier protocol-specific Resolve
      implementations.  The guts of each protocol-specific resolver are in
      the internal resolveOnce method, and we've added a new:
      
        ResolveN(ctx, name, depth)
      
      method to the public interface.  There's also:
      
        Resolve(ctx, name)
      
      which wraps ResolveN using DefaultDepthLimit.  The extra API endpoint
      is intended to reduce the likelyhood of clients accidentally calling
      the more dangerous ResolveN with a nonsensically high or infinite
      depth.  On IRC on 2015-05-17, Juan said:
      
      15:34 <jbenet> If 90% of uses is the reduced API with no chance to
        screw it up, that's a huge win.
      15:34 <wking> Why would those 90% not just set depth=0 or depth=1,
        depending on which they need?
      15:34 <jbenet> Because people will start writing `r.Resolve(ctx, name,
        d)` where d is a variable.
      15:35 <wking> And then accidentally set that variable to some huge
        number?
      15:35 <jbenet> Grom experience, i've seen this happen _dozens_ of
        times. people screw trivial things up.
      15:35 <wking> Why won't those same people be using ResolveN?
      15:36 <jbenet> Because almost every example they see will tell them to
        use Resolve(), and they will mostly stay away from ResolveN.
      
      The per-prodocol versions also resolve recursively within their
      protocol.  For example:
      
        DNSResolver.Resolve(ctx, "ipfs.io", 0)
      
      will recursively resolve DNS links until the referenced value is no
      longer a DNS link.
      
      I also renamed the multi-protocol ipfs NameSystem (defined in
      namesys/namesys.go) to 'mpns' (for Multi-Protocol Name System),
      because I wasn't clear on whether IPNS applied to the whole system or
      just to to the DHT-based system.  The new name is unambiguously
      multi-protocol, which is good.  It would be nice to have a distinct
      name for the DHT-based link system.
      
      Now that resolver output is always prefixed with a namespace and
      unprefixed mpns resolver input is interpreted as /ipfs/,
      core/corehttp/ipns_hostname.go can dispense with it's old manual
      /ipfs/ injection.
      
      Now that the Resolver interface handles recursion, we don't need the
      resolveRecurse helper in core/pathresolver.go.  The pathresolver
      cleanup also called for an adjustment to FromSegments to more easily
      get slash-prefixed paths.
      
      Now that recursive resolution with the namesys/namesys.go composite
      resolver always gets you to an /ipfs/... path, there's no need for the
      /ipns/ special case in fuse/ipns/ipns_unix.go.
      
      Now that DNS links can be things other than /ipfs/ or DHT-link
      references (e.g. they could be /ipns/<domain-name> references) I've
      also loosened the ParsePath logic to only attempt multihash validation
      on IPFS paths.  It checks to ensure that other paths have a
      known-protocol prefix, but otherwise leaves them alone.
      
      I also changed some key-stringification from .Pretty() to .String()
      following the potential deprecation mentioned in util/key.go.
      3ead2443