-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: blob implementation #1342
Conversation
d3c09d2
to
7660794
Compare
7660794
to
52cf8fe
Compare
52cf8fe
to
02584d7
Compare
472a097
to
9624c8a
Compare
6178240
to
a78c3ea
Compare
a36b64d
to
5c6b000
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an amazing progress, I'm blown away. I did provide some feedback here and there only thing I'd call out is that we really should capture dependencies across tasks and we'd have to define those in capability schemas also otherwise they will be ignored during encode.
Other than that I was also thinking when writing spec that it would be a good idea to have separate internal invocations when space usage is increased / decreased so that billing could more simply tap into that without having to make guesses if allocate
resulted in more space use or not. Relatedly there had been various other cases where we want to do batch operations that billing would have trouble with, however it could be also addressed if we had simple internal ops that increase / decreate usage. This is definitely something we need @alanshaw feedback on
if (hasBlob.ok) { | ||
return { | ||
ok: { size: blob.size }, | ||
} | ||
} | ||
|
||
return { | ||
ok: { | ||
size: blob.size, | ||
address: { | ||
url: createUploadUrl.ok.url.toString(), | ||
headers: createUploadUrl.ok.headers, | ||
}, | ||
}, | ||
} | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect allocation to produce same result regardless of whether we have a blob or not, it's just if we do have a blob already we would succeed put without awaiting on user to perform upload and consequently succeed blob/add as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am following the spec, which makes address
optional for this reason? https://github.com/web3-storage/specs/blob/feat/http-put/w3-blob.md#allocate-blob-receipt-schema
In the meantime, latest implementation of blob dd should actually do what you say
6f1b921
to
0668957
Compare
adfb56f
to
15d732c
Compare
🤖 I have created a release *beep* *boop* --- ## [13.3.0](capabilities-v13.2.1...capabilities-v13.3.0) (2024-04-12) ### Features * blob, web3.storage and ucan conclude capabilities together with api handlers ([#1342](#1342)) ([00735a8](00735a8)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
🤖 I have created a release *beep* *boop* --- ## [9.1.0](upload-api-v9.0.1...upload-api-v9.1.0) (2024-04-12) ### Features * blob, web3.storage and ucan conclude capabilities together with api handlers ([#1342](#1342)) ([00735a8](00735a8)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>
Adds implementation of
blob/*
,web3.storage/*
anducan/conclude
handlers and capabilities.Also upgrades to latest ucanto all over the place