Skip to content
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

Adding docs to hypercore-streams #8

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

martinheidegger
Copy link
Contributor

This PR adds documentation for the stream options to the documentation, as the stream options also describe "batch" I based this PR on #6. I will rebase this if necessary.

It also updates links to point to they hypercore-protocol github org.

@@ -63,6 +64,21 @@ class ReadStream extends Readable {
this.push(null)
return cb(null)
}
if (this.batch > 1) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this needs to check if feed.getBatch exists also (remotehypercore does not have this atm)

Copy link
Contributor Author

@martinheidegger martinheidegger Nov 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be good to test the streams against remotehypercore as well? Or in other words: Is it desirable to consider remotehypercore as valid full implementation of the "hypercore-interface"?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already test it in hyperspace. This should only test against the "source of truth" which is hypercore :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about a PR to remote-hypercore that adds getBatch?

if (this.batch > 1) {
const batchStart = this.index
const batchEnd = Math.min(batchStart + this.batch, this.end, this.feed.length)
if (batchStart < batchEnd) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think this would ever trigger an else? ie, can we drop the if

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There could be an "undownload" operation or something alike happening inbetween. But testing for that is surely tricky.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how that would trigger it still

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I looked into it a bit more. I am not sure I am able to phrase this correctly, but you can replicate my findings by throwing an error statement in a else block: } else { throw new Error('foo') } and then run the tests (this case is actually already covered by the tests case.

My understanding, formatted in a way that I could add it as comment to the code :)

// A batched live stream may start with an empty stream, resulting in both
// `batchEnd` and `batchStart` to be `0`. In this case a download needs to take place and
// we fall back to `get()` operation as it will trigger a download of the blocks linearly.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this feels like it should be encapsulated with a IsBatchFinished or something that returns a bool, which you can call inside of if logic. Thank you for your contribution.

@mafintosh
Copy link
Collaborator

Thanks @martinheidegger, you probably just copied over the codebase so maybe @tinchoz49 knows about that 2nd q

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants