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

Separate pull- and -stream packages? #34

Open
dy opened this issue Apr 28, 2017 · 9 comments
Open

Separate pull- and -stream packages? #34

dy opened this issue Apr 28, 2017 · 9 comments

Comments

@dy
Copy link
Member

dy commented Apr 28, 2017

Now many modules due to multiple interfaces look messy, esp. for understanding the API.

Should we split audio-speaker (and others) to

  • pull-audio-speaker for pull-stream
  • stream-audio-speaker or audio-speaker-stream for node stream
  • audio-speaker for plain function
  • [audio-speaker-cli for command-line?]

?

That would make API entrance easier, less single-package maintenance efforts, better docs, better isolation/independence, less weight of a single package, less naming conventions issues (like direct/stream/pull/etc), make for better tests (no need to cross-test stream versions), resolve naming issues (some audio-* modules are not streams already), allow for grouping stream-* and pull-* packages together to organize stacks, e.g. we could separate them in docs. Some people don't use streams, others don't use pull-streams, others don't know what streams are but want to output audio. I'd guess these are separate groups of users.

@jamen @ahdinosaur

@vectrixdevelops
Copy link

This seems a lot better in my opinion. Although I think we should split audio-speaker after the release-2.0 branch is finished and merged.

@jamen
Copy link
Contributor

jamen commented Apr 28, 2017

I 100% agree.

@jamen
Copy link
Contributor

jamen commented Apr 28, 2017

@connorhartley Why not before, just avoid an unnecessary release afterwards?

@dy
Copy link
Member Author

dy commented Apr 28, 2017

@connorhartley we can go v2.0 along with splitting it. That would help you focusing only on functional interface btw.

@vectrixdevelops
Copy link

@jamen @dfcreative Sounds good.

@jamen
Copy link
Contributor

jamen commented Apr 28, 2017

I like the *-stream and *-cli convention opposed to stream-*/cli-* btw, but also like pull-*.

Whichever way it reads better.

@dy
Copy link
Member Author

dy commented Apr 29, 2017

So the list:

@ahdinosaur
Copy link
Member

👍 thumbs up!

@dy
Copy link
Member Author

dy commented Jan 8, 2019

All possible entries:

  • wasm, asm
  • native binding
  • browser / node main
  • pull / push / stream
  • cli / bin
  • transform? plugin?

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

No branches or pull requests

4 participants