I am thinking of firing an issue on Github to collect 3.0 wishlist from the community. What do you say?
-Ian. On Sat, Feb 2, 2019 at 6:12 AM Kun Song <[email protected]> wrote: > I especially interested in reactive programming and cloud native support. > > A reactive Dubbo will be attractive, as the community point out. I even > propose to make Dubbo implements the Reactive Streams specification, which > will integrate back pressure(flow control) and make Dubbo a choice for > stream processing(which is a booming area). Stream processing has many > advantages such as better resource utilization, as far as I know, Java > 9/RxJava/Akka-Streams have already implements Reactive Streams spec, and > have already gained great success. > > Of course cloud native support is a must, we should do it, and HTTP 2 & > RSocket are also interesting feature to me. > > When decide what features Dubbo 3 should have, I think we can make each > feature a proposal, which could including motivation/proposed > changes/interfaces/compatibility/deprecation/test plan …, so more > contributors can get involved in it. > > > [1] http://www.reactive-streams.org/ <http://www.reactive-streams.org/> > > > 在 2019年1月28日，下午10:44，Ian Luo <[email protected] <mailto: > [email protected]>> 写道： > > > > Agree, we should consider seriously both HTTP/2 and rsocket. > > > > Thanks, > > -Ian. > > > > > > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei <[email protected] > <mailto:[email protected]>> > > wrote: > > > >> Lan, > >> Yes, I think http2 and some new protocols such as rsocket can be > >> considered. > >> I will spend some time to study this issue. > >> > >> > >> Warm regards, > >> Taosheng > >> > >> > >> > >> > >> ------------------ Original ------------------ > >> From: Ian Luo <[email protected] <mailto:[email protected]>> > >> Date: Thu,Jan 24,2019 9:58 AM > >> To: dev <[email protected] <mailto:[email protected]>> > >> Subject: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really > >> should start it ASAP > >> > >> > >> > >> Taosheng, > >> > >> In this scenario, it looks like we should use http2 to transport the > >> payload, what do you think? > >> > >> Thanks, > >> -Ian. > >> > >> On Wed, Jan 23, 2019 at 10:35 PM Taosheng Wei <[email protected] > <mailto:[email protected]>> > >> wrote: > >> > >>> I think we can find a binary protocol with strong potential to be a > >> public > >>> application protocol like http, and extend it with security function. > Or > >> if > >>> there aren't such suitable protocols, we can try to formulate a new > >>> protocol. Then make Dubbo support it. > >>> In my opinion, this way may not only solve the security problems, but > >> also > >>> solve the cross-language RPC with Dubbo. > >>> > >>> [email protected] <mailto:[email protected]> < > [email protected] <mailto:[email protected]>> 于2019年1月23日周三 > 下午5:47写道： > >>> > >>>> I have a similar Question as this mail: > >>>> Is Dubbo designed for use on internet? > >>>> I have just join a company last year and our business is all around > the > >>>> world. > >>>> So we have servers on US and ASIA and EU. > >>>> In this condition we use dubbo on internet and keep security by > >> security > >>>> rules that only allow the servers connect to each other. > >>>> > >>>> I think this is not a pretty useage of dubbo，but I cann't find Strong > >>>> evidences to change the situation. > >>>> > >>>> Can any one help me to answer this questions? Thanks a lot. > >>>> > >>>> > >>>> > >>>> ------------------------------ > >>>> 您的朋友：刘志广 > >>>> > >>>> > >>>> *From:* Yuhao Bi <[email protected] <mailto:[email protected]>> > >>>> *Date:* 2019-01-22 22:55 > >>>> *To:* dev <[email protected] <mailto:[email protected]>> > >>>> *Subject:* Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we > really > >>>> should start it ASAP > >>>> Hi lan and community, > >>>> > >>>> Although I have already heard "Dubbo" a few years ago, > >>>> but I just started to learn dubbo after the meetup last year in > Chengdu > >>>> after it became the Apache Dubbo. > >>>> Maybe I'm not such that familiar with the underlying details, but > after > >>>> the continuous participated > >>>> I feel like a part of the community, and free to share my opinion. > >>>> > >>>> So, here is my question and also consider it my suggestion: > >>>> Should we care more about Security? How can we prevent from > >> unauthorized > >>>> remote call? > >>>> - Should we support Authentication and Authorization > >>>> - Should we add Spring Security or Active Directory Service support at > >>> the > >>>> framework level > >>>> > >>>> Thanks, > >>>> Yuhao > >>>> > >>>> > >>>> jun liu <[email protected] <mailto:[email protected]>> > 于2019年1月22日周二 下午5:50写道： > >>>> > >>>>>> I think the online integration test and performance test > >> environment > >>>>> should > >>>>>> be set up for the new features. > >>>>> > >>>>> Agree! We should start as soon as possible, from 2.7.x. > >>>>> > >>>>> Jun > >>>>> > >>>>>> On Jan 22, 2019, at 5:43 PM, Xin Wang <[email protected] > <mailto:[email protected]>> > >>>> wrote: > >>>>>> > >>>>>> I think the online integration test and performance test > >> environment > >>>>> should > >>>>>> be set up for the new features. > >>>>>> > >>>>>> Ian Luo <[email protected] <mailto:[email protected]>> > 于2019年1月22日周二 下午3:04写道： > >>>>>> > >>>>>>> Yuhao, good idea. > >>>>>>> > >>>>>>> BTW, do you have any thought on what Dubbo 3.0 should be? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> -Ian. > >>>>>>> > >>>>>>> > >>>>>>> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <[email protected] > <mailto:[email protected]>> > >> wrote: > >>>>>>> > >>>>>>>> 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 < > https://phoenix.apache.org/roadmap.html> > >>>>>>>> > >>>>>>>> yuneng xie <[email protected] <mailto:[email protected]>> > 于2019年1月22日周二 下午2:25写道： > >>>>>>>> > >>>>>>>>> Hi Ian Luo, > >>>>>>>>> > >>>>>>>>> OK, i'd start to work on it soon. > >>>>>>>>> > >>>>>>>>> Ian Luo <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto: > [email protected]> on > >>>>>>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >
