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

Refactor into a callback based API and layer core.async on top? #39

Open
danielcompton opened this issue Nov 17, 2016 · 2 comments
Open

Comments

@danielcompton
Copy link
Collaborator

S3 beam was built around core.async and works fairly well. However, in re-frame (and other frameworks) apps, a callback based approach may be more natural than creating a pipeline channel. Additionally, it can be a little bit hard to follow the flow of logic through the pipeline when you are making changes that affect multiple steps.

One possible option would be to convert this library so that the core uses callbacks, and that core.async can be provided as a layer on top. This would also make core.async options more configurable if people had different needs.

Thoughts?

@martinklepsch
Copy link
Owner

I'm all for dropping core.async if it can be done in a way that doesn't make the API cumbersome to use. When I started working on this core.async seemed to be the only way to achieve what I wanted but clearly it is not.

@danielcompton As you probably know I haven't done much (probably "any" is more precise) work on this lib in a while, mostly because I haven't used it much. You on the other hand seem to be using it quite a bit so I'd be happy to trust your judgement/direction on how to develop this further. Also please add yourself to the Readme credits if you feel like. We could also consider moving to a different Clojars group so that you can also cut releases as you wish. Might not be worth it as well and either way I'm happy to (at the very least) cut releases.

@danielcompton
Copy link
Collaborator Author

We could also consider moving to a different Clojars group so that you can also cut releases as you wish.

That could be good in the future, although it would mean switching to a different group ID which not everyone would see if they just used lein ancient. Lets leave it as it is for now, but keep it as an open option for the future.

Thanks!

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

2 participants