IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
231: Streaming multiparts: pubsub r=ljedrz a=koivunej
This was seen originally but at least it seemed some months ago that there wasn't a way to process multiparts streaming. Luckily the older js-ipfs-http-client puts the message in query. Later versions related to #228 use multipart bodies, but the topic is still a query argument.
Depends on #230.
* Adds test for the older query part message parsing
* Uses `&'static str` instead of `&'static [u8]` (fixes error messages)
The latest version should leave us failing only the conformance tests related to:
* pinning
* `?timeout=<not sure what unit>`
* refs
* cat
* get
* block/get
* dag/get
* wantlist
This is:
```
146 passing (3m)
21 pending
8 failing
```
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
230: Streaming multiparts at block/put and dag/put r=ljedrz a=koivunej
Supercedes #225 to cover `dag/put`. I'll close the earlier and keep this as a draft while the temp git dependency is in place.
This allows accepting multipart bodies without Content-Length header by using mpart-async. Uploads are limited to 1MB.
As minor fixes this includes checking `dag/put?input-enc=raw` as we don't support any other input-enc at the moment (rust-ipld could read dag-json, this was implemented during phase1 already).
As more minor fixes this includes transformation of LengthRequired rejection to "Missing header: content-length" instead of "UNHANDLED REJECTION".
Fix is needed for #228.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
this is minor change but good for interop. the conformance tests only
exercise the input-enc=raw as js-ipfs-http-client does most of the heavy
work. not checking input-enc could end up someone trying to put a json
dag document expecting it to be transformed to cbor, which we currently
do not support.
227: Assorted improvements, continued r=koivunej a=ljedrz
~~Builds on https://github.com/rs-ipfs/rust-ipfs/pull/226, only the last 5 commits are new.~~
The commit messages describe the specific changes, of which the following are the most interesting:
- don't clone the `Subscription`'s result unless it's ready
- enum-ify the `Subscription` object
Co-authored-by: ljedrz <ljedrz@gmail.com>
226: Assorted improvements to Repo and SubscriptionRegistry r=koivunej a=ljedrz
Individual commits describe the specific changes; notable ones:
- remove the `Arc` and its clones where not needed
- reduce allocations around subscription wakers
- use `futures:🔒:Mutex` instead of `std::sync::Mutex` where applicable
- add a `wipe` method to the stores (useful for tests/benches)
cc https://github.com/rs-ipfs/rust-ipfs/issues/174
Co-authored-by: ljedrz <ljedrz@gmail.com>
223: Arc-ify the Ipfs struct r=koivunej a=ljedrz
This allows us to pass the central `Ipfs` object around when needed, improving what we can do within its child objects. In addition:
- `impl Default for Bitswap` (now possible)
- replace `Arc<Repo>` with a reference to `Ipfs` in `IpldDag` and `Ipns`, which are now created on-the-fly when needed
- poll for `BitswapEvent`s using `NetworkBehaviourEventProcess`
- un`Arc` the `Repo`
Co-authored-by: ljedrz <ljedrz@gmail.com>
221: remove Strategy, improve event handling r=koivunej a=ljedrz
The scope of changes is far greater than I've anticipated, but bear with me.
Key, planned changes:
- remove `bitswap::strategy`
- move `bitswap::Stats` to `ledger`
- introduce `BitswapEvents` emitted by `Bitswap::poll`
- move `Message` into `Ledger`
Drive-by changes forced by current design:
- wrap `Stats` in an `Arc`, make individual stats `AtomicU64`
- add a `Bitswap.queued_blocks` collection populated from `IpfsFuture::poll`
- make some child `bitswap` objects `pub` or `pub(crate)`
- update `Stats` from `IpfsFuture::poll` (good causality-wise, bad encapsulation-wise)
- introduce a `Bitswap.io_events` sender and its `IpfsFuture.bitswap_events` counterpart receiver
Observations:
- `Repo` is something we want to have access to both in `bitswap` (in order to find `want`ed `Block`s) and in `Ipfs` (to handle the higher-level API requests)
- `Ledger`s for the different `PeerId`s contain `Stats` that are updated at `IpfsFuture` level
- `BitswapEvents` don't currently result in anything of interest, due to `Behaviour` not containing the `Repo`
Key takeaway: we need to do some re-designing in order for key objects to have better access to one another.
Co-authored-by: ljedrz <ljedrz@gmail.com>
