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

add goals to readme #1

Merged
merged 5 commits into from
Jan 17, 2018
Merged

add goals to readme #1

merged 5 commits into from
Jan 17, 2018

Conversation

Fishrock123
Copy link
Owner

@jasnell How does this look?

@mcollina you might want to take a peek as well.

I feel like I'm missing a thing or three, but it's a start.

readme.md Outdated
- Buffering of data (for any reason) is done outside of the protocol.
- (Either between, or at the ends of protocol interaction.)
- Errors and data should flow through the same call path.
- Callbacks should be the "EOF" mechanism.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Perhaps add...

  • Protocol assumes one-to-one relationship between consumer/sink. (specifically rules out eventemitter like model)
  • Protocol should make no timing assumptions (echoing the point about the consumer below)

On the point about state, the protocol itself should assume no state between calls. All necessary context should be passed with each call (e.g. using a handle object for context passing).

readme.md Outdated
- Focused on interaction of protocol endpoints rather than full-stream management.
- Buffering of data (for any reason) is done outside of the protocol.
- (Either between, or at the ends of protocol interaction.)
- Errors and data should flow through the same call path.

Choose a reason for hiding this comment

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

I would add that this new protocol is "pull only", not push/pull like streams3.


_The name? something something b~~l~~ob, credit Matteo Collina._

## Goals
Some collective goals for this initiative.

Choose a reason for hiding this comment

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

I would note that we aim for:

  1. a very performance C++ implementation
  2. a very performance JS implementation
  3. something that it can be easily ported on the browser too

readme.md Outdated
As a preface, "protocol" refers to a system with "producer / source" and "consumer / sink" endpoints, where the consumer "pulls" from the producer.

- Protocol and protocol state must be simple, certainly simpler than streams3.
- Focused on interaction of protocol endpoints rather than full-stream management.

Choose a reason for hiding this comment

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

JS level to be able to handover completely to C++ if supported.

readme.md Outdated
@@ -1,9 +1,30 @@
# bob

A Work-In-Progress "streams" implementation via data sources, data sinks, and pull flow.
A Work-In-Progress "streams+" implementation via data producers, data consumers, and pull flow.

Choose a reason for hiding this comment

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

I would add that this is binary only.

Fishrock123 added a commit that referenced this pull request Jan 12, 2018
@Fishrock123
Copy link
Owner Author

@jasnell & @mcollina I updated it, PTAL. I think we should try to condense it a little bit where possible.

readme.md Outdated
- (Either between, or at the ends of protocol interaction.)
- Errors and data should flow through the same call path.
- Callbacks should be the "EOF" mechanism.

Copy link
Collaborator

Choose a reason for hiding this comment

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

In the spirit of condensing ...

The Protocol must be simple:
* Pull-based: The consumer requests ("pulls") data from the producer.
* Binary-only: Data is binary buffers only, "object mode" and string encodings are not supported at the protocol level
* Stateless: The protocol must not require state to be maintained out-of-band
* One-to-one: The protocol assumes a one-to-one relationship between producer and consumer
* Timing agnostic: The protocol makes no timing (sync or async) assumptions.
* No buffering: The protocol must not require buffering (although specific implementations might)
* In-line errors and EOF: Errors, data, and EOF should flow through the same call path.

Fishrock123 pushed a commit that referenced this pull request Jan 15, 2018
@Fishrock123
Copy link
Owner Author

@jasnell @mcollina ok updated. Seems good to me so will land if it also looks good to you.

@jasnell
Copy link
Collaborator

jasnell commented Jan 15, 2018

Sgtm

Copy link

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

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