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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
353: Implement /dns and /resolve r=ljedrz a=ljedrz
Add a rudimentary implementation of the `/dns` and `/resolve` endpoints; putting it out there already, as due to the similarity of these two endpoints I'm not 100% sure how much we want to "condense" their inner workings.
This upgrades or conformance suite stats from
```
170 passing
50 pending
```
to
```
178 passing
42 pending
```
Co-authored-by: ljedrz <ljedrz@gmail.com>
349: Continued pinning r=koivunej a=koivunej
This PR adds the remaining `pin/*` APIs, with a bad implementation of recursive pinning. Aim is to inch forward to see a more proper implementation.
Compared to older pin storage implementations in go-ipfs at least this jumps right into using a "datastore" similar to the previous implementation. However I quickly found that the pin storage could not work on the simple datastore API. Instead of turning the datastore API into versioned and Repo level pin operations retryable on races this adds a version of `PinStore` which assumes locked access.
Recursive pinning is the slowest and most space inefficient variant: store all indirect pins. It doesn't seem wise but I am inclided to keep that at least for this PR. When adding a recursive pin, first the root is marked as `Recursive::Intent`, followed by marking all references as pinned `Indirect` from this root, followed by marking the root as `Recursive::Count(number_of_references)`. Writing down the indirect pins is likely not a proper way to do implement this, as this scheme requires all of the machinery only recording the recursive pinning for the root would require, but has some additional steps, and space use. It does not however require inmemory caching as the storage space is the cache.
There will be a long way to go towards a proper transactional, persistent pin storage (or even supporting one) after this PR but I aim to get the HTTP API tests going in this PR, or at least most of them. Probably scoping out the `pin (add|ls|rm) IpfsPath` for just supporting Cids at the moment.
Definitely not included:
- `pin/rm` with multiple arguments; can't see how could this be possible to implement without proper transactional datastore
- recovery from partial recursive pins
Removed:
- `ipfs::repo::Column::Pin` and related paths
Not sure yet:
- how to structure the `pin/ls` response formatting code
- keep the string-precise anyhow errors or do proper error enums?
TODO:
- `pin/ls` non-streaming response
The `pin/ls` responses are quite difficult beast.
### Checklist (can be deleted from PR description once items are checked)
- [x] **New** code is “linted” i.e. code formatting via rustfmt and language idioms via clippy
- [x] There are no extraneous changes like formatting, line reordering, etc. Keep the patch sizes small!
- [ ] There are functional and/or unit tests written, and they are passing
- [ ] There is suitable documentation. In our case, this means:
- [ ] Each command has a usage example and API specification
- [ ] Rustdoc tests are passing on all code-level comments
- [ ] Differences between Rust’s IPFS implementation and the Go or JS implementations are explained
- attempted this at the `ipfs::Ipfs` level method docs
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
adds the progress reporting, which is a progress notification to the
response stream on every block write *in addition to* a notification
*after* the file has been read (order with the `Added` message doesn't
seem to have been specified).
