Once we have decided what to do in the next. Should we have a website page to publish it? e.g. [1]
[1]. https://phoenix.apache.org/roadmap.html 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] > > > > > > > > > >
