IPIP-356: IPFSClient API #356
Conversation
Change IPIP name, this is the IPFSClient API.
markg85
force-pushed
the
ipfsclient-api
branch
from
f23c161
to
71190d0
Compare
|
Maybe the doc should mention |
Perhaps. But that would be the job of #359 :) You couldn't have known, that spec wasn't on github yet when you made the comment. This spec will do no gateway managing on it's own! Technically in terms of code it will all live in the same repository. Spec wise it's separated. |
|
|
||
| ## Motivation | ||
|
|
||
| There is a need for places that can't quite run full IPFS nodes to still have a great IPFS experience. This could be a multitude of reasons (like constrained network resources, lower powered hardware, etc...). Using a gateway one can already IPFS content in a read-only manner, which is enough for many usecases. With mutiple gateways this approach becomes very distributed. |
There was a problem hiding this comment.
Using a gateway one can already IPFS content
Grammer nit: should be "Using a gateway one can alreadyaccessIPFS content"
| } | ||
| ``` | ||
|
|
||
| Without this convenience wrapper you'd have to manually check if the type is `WEB` (in this example case) that can now be abstracted awar in the `error` function itself. |
|
|
||
| ### interface Url | ||
|
|
||
| The Url object will contain 1 URL that is schema valid for the URL structure. Libraries and tools often already have a Url class that does this for you. Rust for example has the Url class too that should be used in this context. In C++ land with Qt as framework, there is the QUrl class to allow URL validation. |
There was a problem hiding this comment.
Links to the references URL classes per language could be a nice addition here
|
|
||
| The network interface API is intended to be an interface to the API. It's implementation must come from the client application. The reasoning here is that each application implementing this API and/or the client application likely has their own network functionality already that should be reused for handing network traffic. | ||
|
|
||
| An example of how these functions are to be used from an API point fo view is as follows: |
| } | ||
| ``` | ||
|
|
||
| The below details to implement this interface are for the client implementation ony. The API implementations can ignore this part. |
| The library will call this function in an async matter. This will be up to the number defined in `Api.gateway_concurrency`. That effectively defines how many different gateways will potentially be used. | ||
|
|
||
| **Parameters** | ||
| `CID cid` is the `CID` we want to get the date from. Note that in multiple requests for the same `CID` this value will remain the same. The `http_url` will differ. |
Draft for sure!
This spec is intended to specify how a "ipfsclient" works.
It relies on 3 different specs:
The missing specs will be on github later. Will update this message when they are online.