Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 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 于2019年1月22日周二 下午2:25写道: > >> Hi Ian Luo, >> >> OK, i'd start to work on it soon. >> >> Ian Luo 于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 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 于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 behi
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 于2019年1月22日周二 下午2:25写道: > Hi Ian Luo, > > OK, i'd start to work on it soon. > > Ian Luo 于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 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 于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 langu
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
Agree. Pls. keep discussing the wish list for dubbo 3.0. I will init a project on GitHub, and keep collecting good ideas into it. -Ian. On Sun, Feb 3, 2019 at 6:34 PM Kun Song wrote: > An issue will be fine, maybe we can discuss features on mail list, and add > more serious conclusions in that issue. What others think? > > > 在 2019年2月2日,下午7:10,Imteyaz Khan 写道: > > > > +1 in the suggestion. > > > > On Saturday, February 2, 2019, Ian Luo wrote: > > > >> 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 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 >>> ian@gmail.com>> 写道: > >>>> > >>>> Agree, we should consider seriously both HTTP/2 and rsocket. > >>>> > >>>> Thanks, > >>>> -Ian. > >>>> > >>>> > >>>> On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei < > >> weitaosh...@foxmail.com > >>> <mailto:weitaosh...@foxmail.com>> > >>>> 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 mailto:ian@gmail.com>> > >>>>> Date: Thu,Jan 24,2019 9:58 AM > >>>>> To: dev mailto:dev@dubbo.apache.org>> > >>>>> 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 < > >> tswstarpla...@apache.org > >>> <mailto:tswstarpla...@apache.org>> > >>>>> 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. > >>>>>> > >>>>>> zhi_guang_.
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
I guess what Taosheng propose here is a DSL to build REST apis, DSL is good, confluent and concise. > 在 2019年2月3日,下午3:24,jun liu 写道: > > Hi, Taosheng > >> I think we can provide functional api to users for configuring dubbo, >> comparable to xml or annotation configuration. Just like spring 5 provide >> both controller configuration and functional api for http > > > Sounds pretty good, only functional bean registration is a new concept for > me, I will spend some time on it. Would you please help to check its possible > relation with the builder API in here > https://github.com/apache/incubator-dubbo/issues/3431? > > Jun > >> On Feb 3, 2019, at 12:55 AM, Taosheng, Wei wrote: >> >> I think we can provide functional api to users for configuring dubbo, >> comparable to xml or annotation configuration. Just like spring 5 provide >> both controller configuration and functional api for http. >
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
An issue will be fine, maybe we can discuss features on mail list, and add more serious conclusions in that issue. What others think? > 在 2019年2月2日,下午7:10,Imteyaz Khan 写道: > > +1 in the suggestion. > > On Saturday, February 2, 2019, Ian Luo wrote: > >> 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 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 >> ian@gmail.com>> 写道: >>>> >>>> Agree, we should consider seriously both HTTP/2 and rsocket. >>>> >>>> Thanks, >>>> -Ian. >>>> >>>> >>>> On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei < >> weitaosh...@foxmail.com >>> <mailto:weitaosh...@foxmail.com>> >>>> 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 mailto:ian@gmail.com>> >>>>> Date: Thu,Jan 24,2019 9:58 AM >>>>> To: dev mailto:dev@dubbo.apache.org>> >>>>> 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 < >> tswstarpla...@apache.org >>> <mailto:tswstarpla...@apache.org>> >>>>> 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. >>>>>> >>>>>> zhi_guang_...@163.com <mailto:zhi_guang_...@163.com> < >>> zhi_guang_...@163.com <mailto:zhi_guang_...@163.com>> 于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 >
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
Hi, Taosheng > I think we can provide functional api to users for configuring dubbo, > comparable to xml or annotation configuration. Just like spring 5 provide > both controller configuration and functional api for http Sounds pretty good, only functional bean registration is a new concept for me, I will spend some time on it. Would you please help to check its possible relation with the builder API in here https://github.com/apache/incubator-dubbo/issues/3431? Jun > On Feb 3, 2019, at 12:55 AM, Taosheng, Wei wrote: > > I think we can provide functional api to users for configuring dubbo, > comparable to xml or annotation configuration. Just like spring 5 provide > both controller configuration and functional api for http.
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
I think we can provide functional api to users for configuring dubbo, comparable to xml or annotation configuration. Just like spring 5 provide both controller configuration and functional api for http. -- Original -- From: Kun Song Date: Sat,Feb 2,2019 6:12 AM To: dev Subject: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP 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??2810:44??Ian Luo <mailto:ian@gmail.com>> ?? > > Agree, we should consider seriously both HTTP/2 and rsocket. > > Thanks, > -Ian. > > > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei <mailto:weitaosh...@foxmail.com>> > 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 mailto:ian....@gmail.com>> >> Date: Thu,Jan 24,2019 9:58 AM >> To: dev mailto:dev@dubbo.apache.org>> >> 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 > <mailto:tswstarpla...@apache.org>> >> 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. >>> >>> zhi_guang_...@163.com <mailto:zhi_guang_...@163.com> >> <mailto:zhi_guang_...@163.com>> ??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 mailto:byh0...@gmail.com>> >>>> *Date:* 2019-01-22 22:55 >>>> *To:* dev mailto:dev@dubbo.apache.org>> >>>> *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 m
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
+1 in the suggestion. On Saturday, February 2, 2019, Ian Luo wrote: > 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 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 > ian@gmail.com>> 写道: > > > > > > Agree, we should consider seriously both HTTP/2 and rsocket. > > > > > > Thanks, > > > -Ian. > > > > > > > > > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei < > weitaosh...@foxmail.com > > <mailto:weitaosh...@foxmail.com>> > > > 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 mailto:ian@gmail.com>> > > >> Date: Thu,Jan 24,2019 9:58 AM > > >> To: dev mailto:dev@dubbo.apache.org>> > > >> 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 < > tswstarpla...@apache.org > > <mailto:tswstarpla...@apache.org>> > > >> 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. > > >>> > > >>> zhi_guang_...@163.com <mailto:zhi_guang_...@163.com> < > > zhi_guang_...@163.com <mailto:zhi_guang_...@163.com>> 于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. > > >>>> > > >>>> > > >>>> > > >>>>
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 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 ian@gmail.com>> 写道: > > > > Agree, we should consider seriously both HTTP/2 and rsocket. > > > > Thanks, > > -Ian. > > > > > > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei <mailto:weitaosh...@foxmail.com>> > > 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 mailto:ian@gmail.com>> > >> Date: Thu,Jan 24,2019 9:58 AM > >> To: dev mailto:dev@dubbo.apache.org>> > >> 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 <mailto:tswstarpla...@apache.org>> > >> 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. > >>> > >>> zhi_guang_...@163.com <mailto:zhi_guang_...@163.com> < > zhi_guang_...@163.com <mailto:zhi_guang_...@163.com>> 于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 mailto:byh0...@gmail.com>> > >>>> *Date:* 2019-01-22 22:55 > >>>> *To:* dev mailto:dev@dubbo.apache.org>> > >>>> *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 > >>>> a
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
Hi, On Sat, Feb 2, 2019 at 6:12 AM Kun Song 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. Good suggestion. +1 for the feature proposal. > > > [1] http://www.reactive-streams.org/ <http://www.reactive-streams.org/> > > > 在 2019年1月28日,下午10:44,Ian Luo mailto:ian@gmail.com>> > > 写道: > > > > Agree, we should consider seriously both HTTP/2 and rsocket. > > > > Thanks, > > -Ian. > > > > > > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei > <mailto:weitaosh...@foxmail.com>> > > 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 mailto:ian@gmail.com>> > >> Date: Thu,Jan 24,2019 9:58 AM > >> To: dev mailto:dev@dubbo.apache.org>> > >> Subject: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really > >> should start it ASAP > >> > >> > >>>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > -- Best Regards! Huxing
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 mailto:ian@gmail.com>> > 写道: > > Agree, we should consider seriously both HTTP/2 and rsocket. > > Thanks, > -Ian. > > > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei <mailto:weitaosh...@foxmail.com>> > 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 mailto:ian....@gmail.com>> >> Date: Thu,Jan 24,2019 9:58 AM >> To: dev mailto:dev@dubbo.apache.org>> >> 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 > <mailto:tswstarpla...@apache.org>> >> 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. >>> >>> zhi_guang_...@163.com <mailto:zhi_guang_...@163.com> >> <mailto:zhi_guang_...@163.com>> 于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 mailto:byh0...@gmail.com>> >>>> *Date:* 2019-01-22 22:55 >>>> *To:* dev mailto:dev@dubbo.apache.org>> >>>> *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 >>>> fram
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 mailto:ian@gmail.com>> > 写道: > > Agree, we should consider seriously both HTTP/2 and rsocket. > > Thanks, > -Ian. > > > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei <mailto:weitaosh...@foxmail.com>> > 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 mailto:ian....@gmail.com>> >> Date: Thu,Jan 24,2019 9:58 AM >> To: dev mailto:dev@dubbo.apache.org>> >> 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 > <mailto:tswstarpla...@apache.org>> >> 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. >>> >>> zhi_guang_...@163.com <mailto:zhi_guang_...@163.com> >> <mailto:zhi_guang_...@163.com>> 于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 mailto:byh0...@gmail.com>> >>>> *Date:* 2019-01-22 22:55 >>>> *To:* dev mailto:dev@dubbo.apache.org>> >>>> *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 >>>> fram
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
Agree, we should consider seriously both HTTP/2 and rsocket. Thanks, -Ian. On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei 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 > Date: Thu,Jan 24,2019 9:58 AM > To: dev > 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 > 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. > > > > zhi_guang_...@163.com 于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 > > > *Date:* 2019-01-22 22:55 > > > *To:* dev > > > *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 于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 > > > wrote: > > > > > > > > > > I think the online integration test and performance test > environment > > > > should > > > > > be set up for the new features. > > > > > > > > > > Ian Luo 于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 > 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 > > > > >>> > > > > >>> yuneng xie 于2019年1月22日周二 下午2:2
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 Date: Thu,Jan 24,2019 9:58 AM To: dev 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 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. > > zhi_guang_...@163.com ??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 > > *Date:* 2019-01-22 22:55 > > *To:* dev > > *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 ??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 > > wrote: > > > > > > > > I think the online integration test and performance test environment > > > should > > > > be set up for the new features. > > > > > > > > Ian Luo ??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 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 > > > >>> > > > >>> yuneng xie ??2019??1??22?? 2:25?? > > > >>> > > > >>>> Hi Ian Luo, > > > >>>> > > > >>>> OK, i'd start to work on it soon. > > > >>>> > > > >>>> Ian Luo ??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. > > > >>>>> > > > >>>
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
Hi Zhiguang, > In this condition we use dubbo on internet and keep security by security > rules that only allow the servers connect to each other. I want to know how do you apply the security rules to Dubbo. Can you provide more detail on this? Jun > On Jan 23, 2019, at 5:47 PM, zhi_guang_...@163.com wrote: > > 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 <mailto:byh0...@gmail.com> > Date: 2019-01-22 22:55 > To: dev <mailto:dev@dubbo.apache.org> > 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 于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 wrote: > > > > > > I think the online integration test and performance test environment > > should > > > be set up for the new features. > > > > > > Ian Luo 于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 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 > > >>> > > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > > >>> > > >>>> Hi Ian Luo, > > >>>> > > >>>> OK, i'd start to work on it soon. > > >>>> > > >>>> Ian Luo 于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 > > >>> 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 s
Re: 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 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. > > zhi_guang_...@163.com 于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 > > *Date:* 2019-01-22 22:55 > > *To:* dev > > *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 于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 > > wrote: > > > > > > > > I think the online integration test and performance test environment > > > should > > > > be set up for the new features. > > > > > > > > Ian Luo 于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 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 > > > >>> > > > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > > > >>> > > > >>>> Hi Ian Luo, > > > >>>> > > > >>>> OK, i'd start to work on it soon. > > > >>>> > > > >>>> Ian Luo 于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 > > > > >>> wrote: > > > >>>>> > > > >>>>>> Hi folks, > > > >>>>>> > > > >>>>>> I agr
Re: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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. zhi_guang_...@163.com 于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 > *Date:* 2019-01-22 22:55 > *To:* dev > *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 于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 > wrote: > > > > > > I think the online integration test and performance test environment > > should > > > be set up for the new features. > > > > > > Ian Luo 于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 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 > > >>> > > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > > >>> > > >>>> Hi Ian Luo, > > >>>> > > >>>> OK, i'd start to work on it soon. > > >>>> > > >>>> Ian Luo 于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 > > >>> 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 > > >>>&
Re: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
If the RT is acceptable between the data center, this usage is perfectly fine. -Ian. On Wed, Jan 23, 2019 at 5:47 PM zhi_guang_...@163.com wrote: > 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 > *Date:* 2019-01-22 22:55 > *To:* dev > *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 于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 > wrote: > > > > > > I think the online integration test and performance test environment > > should > > > be set up for the new features. > > > > > > Ian Luo 于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 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 > > >>> > > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > > >>> > > >>>> Hi Ian Luo, > > >>>> > > >>>> OK, i'd start to work on it soon. > > >>>> > > >>>> Ian Luo 于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 > > >>> 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 > > >>
Re: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 Date: 2019-01-22 22:55 To: dev 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 于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 wrote: > > > > I think the online integration test and performance test environment > should > > be set up for the new features. > > > > Ian Luo 于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 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 > >>> > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > >>> > >>>> Hi Ian Luo, > >>>> > >>>> OK, i'd start to work on it soon. > >>>> > >>>> Ian Luo 于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 > >>> 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. > >&g
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
> - Reative programming and its fundamental FP start to get adopted. We should consider to support it. It looks like we're thinking about "full stack asynchronization" , I think the Spring4 shoud be upgraded to spring5 Although Spring is an optional component in Dubbo, but spring 5 provides some asynchronous features, such as webFlux, which integrates Rxjava Here is the 《Upgrading to Spring Framework 5.x》[1] , I translated it Chinese and wrote some opinions of my own [2]. [1] https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-5.x [2] http://lovepoem.github.io/2018/09/05/framework/spring5_new_features/ Ian Luo 于2019年1月23日周三 上午11:11写道: > Thanks for Yuhao raising this good point. In my opinion, both ACL and > transaction are important to Dubbo, and the community keep demanding the > support on these areas. We should put them in our roadmap. > > Thanks, > -Ian. > > > On Tue, Jan 22, 2019 at 10:55 PM Yuhao Bi wrote: > > > 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 于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 > > wrote: > > > > > > > > I think the online integration test and performance test environment > > > should > > > > be set up for the new features. > > > > > > > > Ian Luo 于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 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 > > > >>> > > > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > > > >>> > > > Hi Ian Luo, > > > > > > OK, i'd start to work on it soon. > > > > > > Ian Luo 于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 > > > > >>> 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 于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 > > > >>> bandw
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
Thanks for Yuhao raising this good point. In my opinion, both ACL and transaction are important to Dubbo, and the community keep demanding the support on these areas. We should put them in our roadmap. Thanks, -Ian. On Tue, Jan 22, 2019 at 10:55 PM Yuhao Bi wrote: > 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 于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 > wrote: > > > > > > I think the online integration test and performance test environment > > should > > > be set up for the new features. > > > > > > Ian Luo 于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 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 > > >>> > > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > > >>> > > Hi Ian Luo, > > > > OK, i'd start to work on it soon. > > > > Ian Luo 于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 > > >>> 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 于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
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 于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 wrote: > > > > I think the online integration test and performance test environment > should > > be set up for the new features. > > > > Ian Luo 于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 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 > >>> > >>> yuneng xie 于2019年1月22日周二 下午2:25写道: > >>> > Hi Ian Luo, > > OK, i'd start to work on it soon. > > Ian Luo 于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 > >>> 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 于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, > >>
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
> 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 wrote: > > I think the online integration test and performance test environment should > be set up for the new features. > > Ian Luo 于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 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 >>> >>> yuneng xie 于2019年1月22日周二 下午2:25写道: >>> Hi Ian Luo, OK, i'd start to work on it soon. Ian Luo 于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 >>> 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 于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
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
I think the online integration test and performance test environment should be set up for the new features. Ian Luo 于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 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 > > > > yuneng xie 于2019年1月22日周二 下午2:25写道: > > > > > Hi Ian Luo, > > > > > > OK, i'd start to work on it soon. > > > > > > Ian Luo 于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 > > 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 于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
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 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 > > yuneng xie 于2019年1月22日周二 下午2:25写道: > > > Hi Ian Luo, > > > > OK, i'd start to work on it soon. > > > > Ian Luo 于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 > 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 于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. > > >
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 于2019年1月22日周二 下午2:25写道: > Hi Ian Luo, > > OK, i'd start to work on it soon. > > Ian Luo 于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 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 于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 o
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
Hi Ian Luo, OK, i'd start to work on it soon. Ian Luo 于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 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 于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
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 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 于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 liujie...@apache.org on > > dev@dubbo.apache.org > > >
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
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 于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 liujie...@apache.org on > dev@dubbo.apache.org >
Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP
What I am thinking about the next generation of Dubbo should be: - cloud native: should be well integrated into Kubernetes, and Dubbo protocol should be seamlessly go through service mesh sidecar like Envoy. - reactive: should keep the RPC invocation completely reactive - polyglot: Dubbo service should be invoked across different languages. The features I think Dubbo should have(maybe in 2.7): - Integration with other microservice components, like API gateway, monitoring and distributed tracing, distributed transaction, scheduling, and etc. - the Dubbo modules should be separated from the framework and can be used as standalone dependency. For example, the load balancing module can be separated as a library and used by other projects - Integration with standards, like HTTP/2 support. This is important because if we support HTTP/2, it will be easier to integrate with other microservice components that supports HTTP/2. On Thu, Jan 10, 2019 at 6:00 PM Ian Luo wrote: > > 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 liujie...@apache.org on dev@dubbo.apache.org -- Best Regards! Huxing