Identify common use cases that this standard should address

[benlesh]

We need to identify the basic use-cases that need to be met to provide consumers of reactive streams libraries a consistent, but minimal, API.

continued discussion from: https://github.com/Reactive-Streams-Open-Standard/reactive-streams-spec/issues/1

[benlesh]

from @briancavalier:

This is certainly related the scope/goals thread on twitter today. Do we need a new issue to focus specifically on those? For example, "interop" and "interchange" were both mentioned. Promises/A+ was, imho, successful in part because it focused so narrowly on interop. Interchange likely has more surface area.

[benlesh]

@briancavalier. I agree. I think to start with the biggest and most important basic issues should be

• What basic interface should consumers expect?
• How will a consumer subscribe to an Observable stream?
  • what are the expected characteristics and behaviors of that subscription method?
• How will a consumer unsubscribe from an Observable stream?
  • what are the expected characteristics and behaviors of that unsubscription/disposal method?

Also, I think it's important to see how this aligns with the TC39 spec which @jhusain is working on.

[benlesh]

Anyhow, I think for the first phase, interop is what we need to focus on. Sub/Unsub behavior is the key there.

[briancavalier]

Just a quick note on interchange, (not to derail the interop direction) it may be possible to get a base level of API compatibility via fantasy-land. For example, most.js implements fantasy-land's Semigroup, Monoid, Functor, Applicative, and Monad.

[benlesh]

Fantasy-land is an interesting spec, and I think it stands separately from this effort for now.

I think the biggest win for implementors will be getting more consumers to use their libraries, and the biggest win for consumers/library authors will be interop, allowing them to treat reactive stream implementations in a first class way, but without coupling their libs to a specific impl.

[briancavalier]

Yep, I'm all all for staying focused on interop. Just wanted to mention that there may be other existing specs that can provide API level compatibility.

[benlesh]

Started a discussion around subscription and unsubscription here: https://github.com/reactive-streams/reactive-streams-js/issues/4

[viktorklang]

I'm missing a discussion regarding goals and scope.

[benlesh]

@viktorklang that's fair. I think a lot of that was discussed on Twitter. The primary goal here is providing a set of unit tests for interop. The scope is evolving, but currently it centers around sub/unsub semantics and interop.

[viktorklang]

@blesh Why not retain the semantics of the -jvm contracts? (there's been man-years of research poured into them by now)

[benlesh]

I'm game to explore any avenue. But one driver behind this is @jhusain's proposal to the TC39. Keeping with JavaScript conventions is important. I'd have to look at the JVM spec more carefully, as I'm not totally familiar with the contract.

[viktorklang]

@blesh Absolutely. One thing to keep in mind is that the interfaces are for interop, not for user-API, so the most important thing is that they work well for interop between different implementations. Or did you have something else in mind?

[benlesh]

@viktorklang nope. I'm almost purely interested in interop.

If someone gives me an RxJS, Bacon, Highlands or Most.js stream, I want my generic framework to be able to subscribe to it without knowing anything about it.

[viktorklang]

@blesh That's great to hear. Then the jvm equivalents should provide a great starting point IMO!

[briancavalier]

@viktorklang same for me: I'm very interested in interop. The proposal here is a subset of the JVM spec, but doesn't deal with communicating demand. @jhusain's work uses promises, returned in the upstream direction, for that. I've done some (unpublished) experiments with it, and it works. I think it's worth exploring other options, like the JVM spec's onSubscription + request approach, for comparison.

[viktorklang]

@briancavalier I'll all for experimentation! :) Given how much time we spent getting RS-jvm to where it is today I'd encourage to ask questions why things are as they are and why they aren't something else—that saves a bit of time on experiments that have already been made :) (We tried Future-based approaches too). My open question is: Is there something wrong with what we ended up with for JVM (given that we both have a minimized spec and a TCK to validate, it ought to save tons of work to simply port).

TL;DR: Don't hesitate to ask why things are in reactive-streams-jvm :)

[benlesh]

As this is gone stale. Closing the issue