Proposal to collect all asynchronous communication protocols in one place

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to collect all asynchronous communication protocols in one place

JSR166 Concurrency mailing list
Project Reactive Streams
(https://github.com/reactive-streams/reactive-streams-jvm/) provides its
interfaces as a small separate artifact, available on Maven Central
(groupId: org.reactivestreams; artifactId: reactive-streams).
This is very convenient: any other project which wants to be compatible with
Reactive Streams, needs only add that small library.
So did, for example, the project RxJava
(https://github.com/ReactiveX/RxJava).
But they noticed that Reactive Streams is not the only way of communication
between asynchronous activities, and added other communication protocols:
Single, Maybe, Completable, Observable/Observer.

Unfortunately, they did not shape interfaces for that protocols as a small
separate artifact(s).
So a developer who wants to use some of that protocols in his project has to
add the whole RxJava library,
which is silly, because he needs only interfaces, which are few percents of
that code.
After some thought, the developer decides not to use RxJava library, but to
declare his own version of that interfaces.
Anyway, he thinks, my project contains interface Z that is absent in RxJava.

Maybe another developer also reinvented inerface Z, but they have little
chance to know each other and to cooperate.

So the moral of the story is: to achieve interoperability between different
asynchronous libraries,
we need a project which keeps various protocols for asynchronous
communication.
Any developer in the world must be able to propose his own protocol.
An expert council, however, can evaluate each protocol as "recommended",
"duplicate", "of limited use", or "invalid".

And the vital question is: which organization could sponsor such a project?      



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to collect all asynchronous communication protocols in one place

JSR166 Concurrency mailing list
Why do you want to use them outside RxJava? As with Reactive Streams, the interfaces are practically useless without a support library hosting operators for them. As far as I know, nobody even tried to reinvent them and those who are worried about the library size use ProGuard to get rid of the unused parts. I don't see any need to standardize or extract those specialized interfaces from RxJava.

Alexei Kaigorodov via Concurrency-interest <[hidden email]> ezt írta (időpont: 2019. jún. 16., V, 16:45):
Project Reactive Streams
(https://github.com/reactive-streams/reactive-streams-jvm/) provides its
interfaces as a small separate artifact, available on Maven Central
(groupId: org.reactivestreams; artifactId: reactive-streams).
This is very convenient: any other project which wants to be compatible with
Reactive Streams, needs only add that small library.
So did, for example, the project RxJava
(https://github.com/ReactiveX/RxJava).
But they noticed that Reactive Streams is not the only way of communication
between asynchronous activities, and added other communication protocols:
Single, Maybe, Completable, Observable/Observer.

Unfortunately, they did not shape interfaces for that protocols as a small
separate artifact(s).
So a developer who wants to use some of that protocols in his project has to
add the whole RxJava library,
which is silly, because he needs only interfaces, which are few percents of
that code.
After some thought, the developer decides not to use RxJava library, but to
declare his own version of that interfaces.
Anyway, he thinks, my project contains interface Z that is absent in RxJava.

Maybe another developer also reinvented inerface Z, but they have little
chance to know each other and to cooperate.

So the moral of the story is: to achieve interoperability between different
asynchronous libraries,
we need a project which keeps various protocols for asynchronous
communication.
Any developer in the world must be able to propose his own protocol.
An expert council, however, can evaluate each protocol as "recommended",
"duplicate", "of limited use", or "invalid".

And the vital question is: which organization could sponsor such a project?       



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to collect all asynchronous communication protocols in one place

JSR166 Concurrency mailing list
Asynchronous interfaces are being reinvented for decades. Look at
https://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html
<https://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html>  
- does not it resembles io.reactivex.SingleObserver? Or CompletableFuture?
This is because there are universal principles of asynchronous
communications, and any asynchronous library designers follow them
unconsciously, reinventing Publishers and Subscribers of various flavours,
but being confident that that interfaces are useless outside their project.

As a result, different asynchronous libraries cannot communicate directly.
They cannot reuse parts of each other and have to reinvent not only
interfaces, but also implementations. Users waste time reinventing
connectors between libraries. Tests developed for one library cannot be
applied to another etc. All this is hard work which can be avoided.



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to collect all asynchronous communication protocols in one place

JSR166 Concurrency mailing list
Each of those APIs have design goals, feature sets, performance expectations and language limitations to work with. Trying to standardize them would lead to either the lowest common denominator or the union of a lot of possibilities, which are equally limiting in practice.

For example, CompletionStage is eager but SingleSource is lazy. Which one should be the standard and what should the other party do? Would you support typed exceptions as part of the signature or not? Should some kind of context be traveling along with items? Should be there a way to work with items requiring lifecycle management? What if the language doesn't support union types or structure-based type matching? All require different API design even though the most fundamental underlying principle is signal flow.

Do you have a specific async problem you want to solve that is not covered by existing libraries or frameworks?

Alexei Kaigorodov via Concurrency-interest <[hidden email]> ezt írta (időpont: 2019. jún. 16., V, 18:55):
Asynchronous interfaces are being reinvented for decades. Look at
https://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html
<https://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html
- does not it resembles io.reactivex.SingleObserver? Or CompletableFuture?
This is because there are universal principles of asynchronous
communications, and any asynchronous library designers follow them
unconsciously, reinventing Publishers and Subscribers of various flavours,
but being confident that that interfaces are useless outside their project.

As a result, different asynchronous libraries cannot communicate directly.
They cannot reuse parts of each other and have to reinvent not only
interfaces, but also implementations. Users waste time reinventing
connectors between libraries. Tests developed for one library cannot be
applied to another etc. All this is hard work which can be avoided.



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to collect all asynchronous communication protocols in one place

JSR166 Concurrency mailing list
>Do you have a specific async problem you want to solve that is not covered
by existing libraries or frameworks?
No, I have no async problems.




--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest