Standardize API

[donato]

Hey @yosbelms - I love what you're doing here!

I think a strength for the project, and the community would be if all the different projects had the same/standardized API.

The ultimate goal is that users can switch between libraries which will support their use-case better. Whether that is in terms of performance or new features.

Pieces that overlap with existing libraries could use the same namespace, for example csp and functions which do the same thing, could have the same name (like csp.go versus csp.run).

[yosbelms]

@donato I undestand your concern, I see the strength of a standarized API, but the only thing Aryn and js-csp shares is Hoare's CSP model, Aryn is a different aproach, and while some API (run/go, for example) may look equal at the first glance, but the arguments are different.

That said, I propose to address this issue with a polyfill shim.

Editted

[yosbelms]

@donato, @egreaves, I mean to make a separated file named stdapi.js which will contain a sort of shim to use js-csp api in Aryn.

[donato]

Thanks for the detailed response. Link to Hoare's CSP model.

If they are doing two different things, then I totally agree they should have different names/apis. At that point, it's not really the responsibility of aryn to create shims, although it is helpful nonetheless!

[yosbelms]

Thanks for the sweet link, here another which helped me to smash my brain in early days of CSP research. I'll make a span soon to explain the main differences beteen Aryn and js-csp.

[donato]

Wow that's a long read! Thanks for sharing, I'd like to peruse it when I get a chance.

On Wed, May 4, 2016, 2:21 PM Yosbel Marín notifications@github.com wrote:

Thanks for the sweet link, here http://www.neng.usu.edu/classes/ece/6750/cspbook.pdf another which helped me to smash my brain in early days of CSP research. I'll make a span soon to explain the main differences beteen Aryn and js-csp.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/yosbelms/aryn/issues/2#issuecomment-216955403

[yosbelms]

Why Aryn?

The Aryn base design mimics the behaviour of CSP in Go through reverse engineering. The goal is to bring CSP to the javascript asynchronous world. Because that, I've taken into account some javascript key-concepts that has helped us to deal with the asynchronous beast(in @jlongster words). Those are:

• Events: This is not just the first and main approach to handle asynchronous tasks in javascript, it is also the native approach in the browsers.
• Callbacks: callbacks has been losing ground taked by Promises, but through callbacks is how Node.js handles asynchronism. The callbacks has not been addressed in Aryn yet, but is the next stop in its roadmap.
• Promises: promises are everywhere in javascript, regardless we prefer or not it has proved to be a successful solution for javascript asynchronism. So, supporting promises provide us integration with a big part of the javascript ecosystem.

About design

Aryn is composed by 3 main classes: Runner, Channel and Suspender. The Runner class is the responsible to manage the couroutines life-cicle. Channel and Runer classes are decoupled between them, each one doesn't know about the existence of the other one, but both knows about Suspender which allows Runner to accept a decoupled implementation of any feature which stops and reasumes its execution based on custom strategies, for example, yield aryn.suspend(100) suspends the execution of the current runner during 100 milliseconds, yield aryn.receive(ch) receive a value from a channel once the channel is ready to give it.

So, the result is a lean and lightweight library to bring CSP to javascript, and kindly integrates in the javascript ecosystem allowing you to use it along with your preferred library based on events, callbacks, or promises.

PS: Thanks @jlongster for this article, it is inspiring.

[yosbelms]

So, I think there is nothing more to say in this thread