Great! With this we would be able to support Rx programming model and Stream communication.
I’d like to give a review on it. Jun > On Mar 7, 2019, at 3:05 PM, yuneng xie <[email protected]> wrote: > > Hi folks, > > the first stage of the reative-stream support has been finished. we now can > using Mono/Flux as return value. i have raised a pr : > https://github.com/apache/incubator-dubbo/pull/3609 . all code is in the > module called dubbo-rpc-rsocket. > > i would try to complete the feature so that we can use Mono/Flux as args in > rpc. > > > > > > yuneng xie <[email protected]> 于2019年1月22日周二 下午2:25写道： > >> Hi Ian Luo, >> >> OK, i'd start to work on it soon. >> >> Ian Luo <[email protected]> 于2019年1月17日周四 下午2:01写道： >> >>> Hi Yuneng, >>> >>> Sounds interesting. I am especially interested in reactive programming >>> support. Pls. go ahead to try implement it on 3.x branch. >>> >>> Thanks, >>> -Ian. >>> >>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <[email protected]> wrote: >>> >>>> Hi folks, >>>> >>>> I agreed with Ian Luo on the improvement list. I also got some idea in >>> my >>>> mind. I'd just share with you two points below in detail which i'm most >>>> interested in right now. >>>> >>>> 1. Upgrade the core abstraction "Invoker", which works in sync mode, >>> to an >>>> abstraction works in async mode. then we can construct >>>> InvocationChain/FilterChain that works in async mode. A core >>> abstraction >>>> works in async mode would simplify the sync/async logic. We no longer >>> need >>>> to repeat the logic about sync-mode/async-mode in each ProtocolInvoker. >>>> ProtocolInvoker could concentrate on async logic and we could handle >>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain into a >>>> SyncInvocationChain. >>>> >>>> 2. Support using stream-value (Fowable, Flux...) as param/returnType. >>>> really a nice feature. >>>> >>>> Please let me known your opinion on my points. I'm also glad to just >>> give >>>> it a try and raise a pr. >>>> >>>> >>>> >>>> Ian Luo <[email protected]> 于2019年1月10日周四 下午6:00写道： >>>> >>>>> Hi folks, >>>>> >>>>> Finally we managed to ramp down version 2.7.0 development, and >>> hopefully >>>> we >>>>> can start the vote in the early of the next week. But the main >>> purpose of >>>>> this email is not a release announcement. Instead, since we now have >>>>> bandwidth, let's consider and discuss what we should focus out from >>> many >>>>> stuff we want to do. For example, we may focus more on issue and pull >>>>> request on GitHub, or we may plan 2.7 minor releases immediately >>> after we >>>>> release 2.7.0. But today I'd like to bring up one longer term plan >>> which >>>>> I'm now caring most, that is, how we define what version 3.0 is? and >>> when >>>>> can we get start on it? In my opinion, we need to start it right from >>>> this >>>>> moment. >>>>> >>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on the >>> same >>>>> topic [1] in July this year. I summarize his points here if you are >>> too >>>>> impatient to read through the contents of his email :p: >>>>> >>>>> 1. Need to enhance the current extension mechanism >>>>> 2. Need to enhance the code base for better maintenance >>>>> 3. Need to support async >>>>> 4. Need to decouple registry server and config server >>>>> 5. Need to support Java8 and above so that we can use advanced >>> features >>>> in >>>>> Dubbo's core >>>>> >>>>> I agree with most of his points in this good proposal. >>>>> >>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0, or >>> in >>>> the >>>>> other word, how do the community expect from Dubbo 3.0. In my >>> opinion, I >>>>> think we need to answer the following questions in this major release: >>>>> >>>>> - Today the boundary between messaging and remoting call gets blur. We >>>> may >>>>> need to consider to support streaming at the protocol level. >>>>> - Reative programming and its fundamental FP start to get adopted. We >>>>> should consider to support it. >>>>> - Dubbo should be redesigned to support async better, and treats >>> async as >>>>> the first class citizen. We do support async feature in 2.7.0 release >>> but >>>>> it is not so perfect. >>>>> - Micro-services has been widely adopted. How Dubbo works seamlessly >>> with >>>>> micro-services becomes a question mark. We need to look into the >>> inter-op >>>>> between Dubbo and micro-services's registry server/config server. The >>>>> support on separating registry server and config server in 2.7.0 >>> release >>>> is >>>>> a good start, but there are still lots of further works remaining >>> with no >>>>> doubt. >>>>> - Once we conquer seamless micro-services support, we still need to >>> take >>>>> one step further to think about K8S integration. After all, K8S and >>>> service >>>>> mesh built above it are now considered the best way for micro-services >>>>> deployment. >>>>> - How we define mini-dubbo, or phrase in another way, what the minimal >>>>> feature set we should define for Dubbo framework. The reason behind >>> this >>>>> is, it is very helpful for developing more language supports from the >>>>> community. This also means, we need to modularize Dubbo further, to >>> make >>>> it >>>>> a reference implementation for other languages. >>>>> >>>>> In short, I suggest we need to focus on streaming protocol, Rx/FP, >>> native >>>>> async, micro-services support, refactor/modularize areas. Of course, >>>> there >>>>> are more I don't mention in this email, for examples: how we make >>> Dubbo >>>>> more resilient? how we support HTTP/2? and more. >>>>> >>>>> Pls. let me know your opinion on what I and Liujie proposed, and share >>>> your >>>>> thought on what kind of features really matter to you. >>>>> >>>>> Thanks, >>>>> -Ian. >>>>> >>>>> >>>>> 1. Proposal for Dubbo 3.0 from [email protected] on >>>>> [email protected] >>>>> >>>> >>> >>
