-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
This seems a lot better in my opinion. Although I think we should split |
I 100% agree. |
@connorhartley Why not before, just avoid an unnecessary release afterwards? |
@connorhartley we can go v2.0 along with splitting it. That would help you focusing only on functional interface btw. |
@jamen @dfcreative Sounds good. |
I like the Whichever way it reads better. |
So the list:
|
👍 thumbs up! |
All possible entries:
|
Now many modules due to multiple interfaces look messy, esp. for understanding the API.
Should we split
audio-speaker
(and others) topull-audio-speaker
for pull-streamstream-audio-speaker
oraudio-speaker-stream
for node streamaudio-speaker
for plain functionaudio-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 (someaudio-*
modules are not streams already), allow for groupingstream-*
andpull-*
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
The text was updated successfully, but these errors were encountered: