Skip to content

GitLab

Switch branch/tag
  1. 26 Sep, 2016 1 commit
  3. 20 Sep, 2016 1 commit
  5. 09 Sep, 2016 1 commit
  7. 26 Aug, 2016 1 commit
  9. 20 Aug, 2016 1 commit
  11. 26 Jul, 2016 1 commit
  13. 02 Jul, 2016 1 commit
  15. 01 Jul, 2016 1 commit
  17. 24 Jun, 2016 1 commit
  19. 12 Jun, 2016 2 commits
  21. 17 Apr, 2016 2 commits
  23. 11 Apr, 2016 1 commit
  25. 07 Apr, 2016 1 commit
  27. 30 Mar, 2016 1 commit
  29. 09 Mar, 2016 1 commit
  31. 31 Jan, 2016 2 commits
  33. 30 Jan, 2016 2 commits
  35. 12 Jan, 2016 1 commit
  37. 05 Jan, 2016 2 commits
  39. 02 Nov, 2015 1 commit
  41. 02 Oct, 2015 1 commit
  43. 30 Sep, 2015 1 commit
  45. 20 May, 2015 2 commits
    • W. Trevor King's avatar
      namesys/dns: Pluggable lookupTXT field · 1e6594d0
      W. Trevor King authored 
      So we can attach a mock lookup function for testing.
      1e6594d0
    • 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
  47. 27 Apr, 2015 1 commit
  49. 31 Mar, 2015 1 commit
  51. 25 Feb, 2015 1 commit
    • Henry's avatar
      rewrote import paths of go.net/context to use golang.org/x/context · 92d08db7
      Henry authored 
      - updated go-ctxgroup and goprocess
ctxgroup: AddChildGroup was changed to AddChild. Used in two files:
- p2p/net/mock/mock_net.go
- routing/dht/dht.go

- updated context from hg repo to git
prev. commit in hg was ad01a6fcc8a19d3a4478c836895ffe883bd2ceab. (context: make parentCancelCtx iterative)
represents commit 84f8955a887232b6308d79c68b8db44f64df455c in git repo

- updated context to master (b6fdb7d8a4ccefede406f8fe0f017fb58265054c)

Aaron Jacobs (2):
net/context: Don't accept a context in the DoSomethingSlow example.
context: Be clear that users must cancel the result of WithCancel.

Andrew Gerrand (1):
go.net: use golang.org/x/... import paths

Bryan C. Mills (1):
net/context: Don't leak goroutines in Done example.

Damien Neil (1):
context: fix removal of cancelled timer contexts from parent

David Symonds (2):
context: Fix WithValue example code.
net: add import comments.

Sameer Ajmani (1):
context: fix TestAllocs to account for ints in interfaces
      92d08db7
  53. 28 Jan, 2015 1 commit
  55. 02 Jan, 2015 1 commit
    • Juan Batiz-Benet's avatar
      crypto -> p2p/crypto · cc0d7c9b
      Juan Batiz-Benet authored 
      The crypto package moves into p2p. Nothing in it so far is ipfs
specific; everything is p2p-general.
      cc0d7c9b
  57. 08 Oct, 2014 1 commit