- 21 May, 2015 24 commits
-
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Juan Batiz-Benet authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
-
Jeromy authored
Also more refactoring of bitswap in general, including some perf improvements and eventlog removal. clean up, and buffer channels move some things around correctly buffer work messages more cleanup, and improve test perf remove unneccessary test revert changes to bitswap message, they werent necessary
-
Juan Batiz-Benet authored
silence error log on shutdown
-
Jeromy authored
-
Juan Batiz-Benet authored
do http server properly so daemon can shut down
-
Jeromy authored
-
Juan Batiz-Benet authored
Stdin parsing optional arg
-
Juan Batiz-Benet authored
travis is very slow atm, so we're not running 1.3 builds for a while.
-
Juan Batiz-Benet authored
remove inflect package
-
Juan Batiz-Benet authored
Fix: Using the `dnslink` feature led to infinite redirects
-
Juan Batiz-Benet authored
fix silent refs failure
-
Juan Batiz-Benet authored
clean up and fix init permissions handling
-
- 20 May, 2015 16 commits
-
-
Christian Couder authored
License: MIT Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
-
Jeromy authored
-
Christian Couder authored
License: MIT Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
-
Christian Couder authored
License: MIT Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
-
Knut Ahlers authored
fixes #1233
-
Jeromy authored
-
Jeromy authored
-
Juan Batiz-Benet authored
Rework mutable namespace resolution to handle recursion
-
W. Trevor King authored
Shifting the generic testResolution helper from the protocol-specific dns_test.go to the generic namesys_test.go.
-
W. Trevor King authored
-
W. Trevor King authored
So we can attach a mock lookup function for testing.
-
W. Trevor King authored
Previously we had a confusing situation, with: * single-arg doc: published name <name> to <value> * double-arg doc: published name <value> to <name> * implementation: Published name <name> to <value> Now we have the uniform: Published to <name>: <value> With the following goals: 1. It's clear that we're writing <value> to <name>'s IPNS slot in the DHT. 2. We preserve the order of arguments from the command-line invocation: $ ipfs name publish <name> <value> Published to <name>: <value>
-
W. Trevor King authored
And add a generic 'ipfs resolve' to handle cross-protocol name resolution.
-
W. Trevor King authored
This lets users resolve (recursively or not) DNS links without pulling in the other protocols. That makes an easier, more isolated target for alternative implemenations, since they don't need to understand IPNS, proquint, etc. to handle these resolutions.
-
W. Trevor King authored
For explicitly enabling recursive behaviour (it was previously always enabled). That allows folks who are interested in understanding layered indirection to step through the chain one link at a time.
-
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.
-