GitLab

Discussion with Juan on IRC ([1] through [2]) lead to this adjusted
JSON output.  Benefits over the old output include:

* deduplication (we only check the children of a given Merkle node
  once, even if multiple arguments resolve to that hash)

* alphabetized output (like POSIX's ls).  As a side-effect of this
  change, I'm also matching GNU Coreutils' ls output (maybe in POSIX?)
  by printing an alphabetized list of non-directories (one per line)
  first, with alphabetized directory lists afterwards.

[1]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41725570&page=5
[2]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41726547&page=5

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

This doesn't affect the text output, which was already using a
stringified name.  The earlier stringification does change the JSON
output from an enumeration integer (e.g. 2) to the string form
(e.g. "File").  If/when we transition to Merkle-object types named by
their hash, we will probably want to revisit this and pass both the
type hash and human-readable-but-collision-prone name on to clients.

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

Change the approach to the directory-header control so we can set the
Argument value in the JSON response.

Stripping the trailing newline from the JSON output is annoying, but
looking over [1] I saw no easy way to add a newline to the JSON
output.  And with the general framework that commands/ attempts to be,
it feels a bit funny to customize the JSON output for a command-line
program.  Perhaps a workable solution is to have the command-line
client append newlines to any output that otherwise lacks them?  But
that seems like a change best left to a separate series.

[1]: http://golang.org/pkg/encoding/json/

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

To be less confusing to newcomers (the IPFS filesystem isn't
Unix-specific anyway, and it isn't even very POSIX-specific [1,2,3]).
I'm a bit uncertain about having one name for users and another for
devs, but the consensus seems to be that mainaining two names is worth
the trouble [4].  We also kicked around:

* 'files' (plural),
* 'filesystem' (too long), and
* 'fs' (redundant after 'ipfs', even though IPFS isn't just about
  filesystems)

on IRC [5 through 6].  I wish there was a more evocative term.  I'm
never sure where "file" lands on the scale between "filesysytem",
"everything is a file", "a single chunk of data with an associated
inode".  But we can't think of anything better.

[1]: https://github.com/ipfs/go-ipfs/pull/1348#issuecomment-110529070
[2]: https://github.com/ipfs/go-ipfs/pull/1348#issuecomment-110529921
[3]: https://github.com/ipfs/go-ipfs/pull/1136/files#r29377283
  In my response to this (no longer visibile on GitHub):

  On Wed, Apr 29, 2015 at 01:30:04PM -0700, Juan Batiz-Benet wrote:
  > > +package fsnode
  >
  > i think this package should be called `unixfs` as that's the
  > abstraction that this is calling to.

  Will do, although I don't see what's especially Unix-y about these
  file nodes.

[4]: https://github.com/ipfs/go-ipfs/pull/1348#issuecomment-110529811
[5]: https://botbot.me/freenode/ipfs/2015-06-09/?msg=41428456&page=5
[6]: https://botbot.me/freenode/ipfs/2015-06-09/?msg=41430703&page=5

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

Folks operating at the Unix-filesystem level shouldn't care about that
level of Merkle-DAG detail.  Before this commit we had:

  $ ipfs unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox:
  ... several lines of empty-string names ...

And with this commit we have:

  $ ipfs unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox

I also reworked the argument-prefixing (object.Argument) in the output
marshaller to avoid redundancies like:

  $ ipfs unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox:
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox

As a side-effect of this rework, we no longer have the trailing blank
line that we used to have after the final directory listing.

The new ErrImplementation is like Python's NotImplementedError, and is
mostly a way to guard against external changes that would need
associated updates in this code.  For example, once we see something
that's neither a file nor a directory, we'll have to update the switch
statement to handle those objects.

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

This is similar to 'ipfs ls ...', but it:

* Lists file sizes that match the content size:

    $ ipfs --encoding=json unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4
    {
      "Objects": [
        {
          "Argument": "/ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4",
          "Links": [
            {
              "Name": "busybox",
              "Hash": "QmPbjmmci73roXf9VijpyQGgRJZthiQfnEetaMRGoGYV5a",
              "Size": 1947624,
              "Type": 2
            }
          ]
        }
      ]
    }
    $ ipfs cat /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox | wc -c
    1947624

  'ipfs ls ...', on the other hand, is using the Merkle-descendant
  size, which also includes fanout links and the typing information
  unixfs objects store in their Data:

    $ ipfs --encoding=json ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4
    {
      "Objects": [
        {
          "Hash": "/ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4",
          "Links": [
            {
              "Name": "busybox",
              "Hash": "QmPbjmmci73roXf9VijpyQGgRJZthiQfnEetaMRGoGYV5a",
              "Size": 1948128,
              "Type": 2
            }
          ]
        }
      ]
    }

* Has a simpler text output corresponding to POSIX ls [1]:

    $ ipfs unixfs ls /ipfs/QmV2FrBtvue5ve7vxbAzKz3mTdWq8wfMNPwYd8d9KHksCF/gentoo/stage3/amd64/2015-04-02
    bin
    dev
    etc
    proc
    run
    sys
    $ ipfs ls /ipfs/QmV2FrBtvue5ve7vxbAzKz3mTdWq8wfMNPwYd8d9KHksCF/gentoo/stage3/amd64/2015-04-02
    QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4 1948183 bin/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       dev/
    QmUz1Z5jnQEjwr78fiMk5babwjJBDmhN5sx5HvPiTGGGjM 1207    etc/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       proc/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       run/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       sys/

  The minimal output allows us to start off with POSIX compliance and
  then add options (which may or may not be POSIX compatible) to
  adjust the output format as we get a better feel for what we need
  ([2] through [3]).

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html
[2]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41724727&page=5
[3]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41725146&page=5

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

the iptb tests are failing all the time on travis. It's possible
this is still a port problem, and it may be something else.
Regardless, right now they're just adding noise.

Otherwise they clash with each other if running on the same machine

This PR moves the addition of new blocks to our wantlist (and their
subsequent broadcast to the network) outside of the clientWorker loop.
This allows blocks to more quickly propogate to peers we are already
connected to, where before we had to wait for the previous findProviders
call in clientworker to complete before we could notify our partners of
the next blocks that we want. I then changed the naming of the
clientWorker and related variables to be a bit more appropriate to the
model. Although the clientWorker (now named providerConnector) feels a
bit awkward and should probably be changed.

fix test assumption

Let's test 'ipfs add' with stdin input too.

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

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>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

This may take care of the daemon clashing on travis.

This commit allows arbitrary json input to set.
It also tests this with sharness.

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

update hash for bigfile

update iptb dependency again, and pick different ports for each iptb cluster

try and fix godeps crap

If you want to get only the hashes (i.e. the previous behaviour), you can use
the `--quiet` flag.

I want to follow this up with a thorough execution of my x/tool/cmd/eg experiments (https://github.com/ipfs/go-ipfs/compare/errRampage)

Also changed the ipns dns resolution to use the "dnslink" format