GitLab

we shouldn't use internal packages.

License: MIT
Signed-off-by: Juan Batiz-Benet <juan@benet.ai>

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

- Modified Godeps/Godeps.json by hand
- [TEST] Updated welcome docs hash to sharness
- [TEST] Updated contact doc
- [TEST] disabled breaking test (t0080-repo refs local)

The net package is the next to move. It will be massaged
a bit still to fix the Network / "NetworkBackend" conflict.

in many places, entries are assigned from one slice to another and in
different goroutines. In one place, entries were modified (in the
queue). To avoid shared mutable state, probably best to handle entries
by value.

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

it seems to make sense since, in each place, the Key and Priority
represent the same information

b/c you know the saying...

"It is better to have 100 functions operate on one data structure than
10 functions on 10 data structures."

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

performing CR in the form of a PR. Let me know what you think.

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

make vendor

to emphasize idempotence

comes at the cost of O(n) Blocks() method.

so there's one less name to think about

A nice invariant for bitswap sessions:

        Senders and receivers can trust that messages do not contain
        duplicate blocks or duplicate keys. Backing the message with a
        map enforces this invariant.

        This comes at the cost of O(n) getters.

implementation will be patched to ensure bitswap messages cannot contain
duplicate blocks or keys

![](http://m.memegen.com/77n7dk.jpg)

Move go-ipfs/bitswap package to go-ipfs/exchange/bitswap

* Delineates the difference between the generic exchange interface and
  implementations (eg. BitSwap protocol)

  Thus, the bitswap protocol can be refined without having to overthink
  how future exchanges will work. Aspects common to BitSwap and other
  exchanges can be extracted out to the exchange package in piecemeal.

  Future exchange implementations can be placed in sibling packages next
  to exchange/bitswap. (eg. exchange/multilateral)