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>
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.
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.
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.
commands/object: remove objectData() and objectLinks() helpers
resolver: added context parameters
sharness: $HASH carried the \r from the http protocol with
sharness: write curl output to individual files
http gw: break PUT handler until PR#1191
The last references to CastToReaders were commented out in 6faeee83
(cmds2/add: temp fix for -r. horrible hack, 2014-11-11) and then
removed completely in 032e9c29 (core/commands2: Updated 'add' command
for new file API, 2014-11-16).
The last references to CastToStrings was removed in a0bd29d5
(core/commands2: Fixed swarm command for new arguments API,
2014-11-18).
The change to an array of readers comes from e096060b
(refactor(core/commands2/add) split loop, 2014-11-06), where it's used
to setup readers for each path in the argument list. However, since
6faeee83 (cmds2/add: temp fix for -r. horrible hack, 2014-11-11) the
argument looping moved outside of add() and into Run(), so we can drop
the multiple-reader support from add().
Adding a file can create multiple nodes (e.g. the splitter can chunk
the file into several blocks), but:
1. we were only appending a single node per reader to our returned
list, and
2. we are only using the final node in that returned list,
so this commit also adjusts add() to return a single node reference
instead on an array of nodes.
This changes .go-ipfs to .ipfs everywhere.
And by the way this defines a DefaultPathName const
for this name.
License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
We now consider debugerrors harmful: we've run into cases where
debugerror.Wrap() hid valuable error information (err == io.EOF?).
I've removed them from the main code, but left them in some tests.
Go errors are lacking, but unfortunately, this isn't the solution.
It is possible that debugerros.New or debugerrors.Errorf should
remain still (i.e. only remove debugerrors.Wrap) but we don't use
these errors often enough to keep.
This commit adds a new set of sharness tests for pinning, and addresses
bugs that were pointed out by said tests.
test/sharness: added more pinning tests
Pinning is currently broken. See issue #1051. This commit introduces
a few more pinning tests. These are by no means exhaustive, but
definitely surface the present problems going on. I believe these
tests are correct, but not sure. Pushing them as failing so that
pinning is fixed in this PR.
make pinning and merkledag.Get take contexts
improve 'add' commands usage of pinning
FIXUP: fix 'pin lists look good'
ipfs-pin-stat simple script to help check pinning
This is a simple shell script to help check pinning.
We ought to strive towards making adding commands this easy.
The http api is great and powerful, but our setup right now
gets in the way. Perhaps we can clean up that area.
updated t0081-repo-pinning
- fixed a couple bugs with the tests
- made it a bit clearer (still a lot going on)
- the remaining tests are correct and highlight a problem with
pinning. Namely, that recursive pinning is buggy. At least:
towards the end of the test, $HASH_DIR4 and $HASH_FILE4 should
be pinned indirectly, but they're not. And thus get gc-ed out.
There may be other problems too.
cc @whyrusleeping
fix grep params for context deadline check
fix bugs in pin and pin tests
check for block local before checking recursive pin
humanize bandwidth output
instrument conn.Conn for bandwidth metrics
add poll command for continuous bandwidth reporting
move bandwidth tracking onto multiaddr net connections
another mild refactor of recording locations
address concerns from PR
lower mock nodes in race test due to increased goroutines per connection
