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 <[email protected]> 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 <[email protected]> 写道： > > > > +1 in the suggestion. > > > > On Saturday, February 2, 2019, Ian Luo <[email protected]> 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 <[email protected]> wrote: > >> > >>> I especially interested in reactive programming and cloud native > support. > >>> > >>> A reactive Dubbo will be attractive, as the community point out. I even > >>> propose to make Dubbo implements the Reactive Streams specification, > >> which > >>> will integrate back pressure(flow control) and make Dubbo a choice for > >>> stream processing(which is a booming area). Stream processing has many > >>> advantages such as better resource utilization, as far as I know, Java > >>> 9/RxJava/Akka-Streams have already implements Reactive Streams spec, > and > >>> have already gained great success. > >>> > >>> Of course cloud native support is a must, we should do it, and HTTP 2 & > >>> RSocket are also interesting feature to me. > >>> > >>> When decide what features Dubbo 3 should have, I think we can make each > >>> feature a proposal, which could including motivation/proposed > >>> changes/interfaces/compatibility/deprecation/test plan …, so more > >>> contributors can get involved in it. > >>> > >>> > >>> [1] http://www.reactive-streams.org/ <http://www.reactive-streams.org/ > > > >>> > >>>> 在 2019年1月28日，下午10:44，Ian Luo <[email protected] <mailto: > >>> [email protected]>> 写道： > >>>> > >>>> Agree, we should consider seriously both HTTP/2 and rsocket. > >>>> > >>>> Thanks, > >>>> -Ian. > >>>> > >>>> > >>>> On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei < > >> [email protected] > >>> <mailto:[email protected]>> > >>>> wrote: > >>>> > >>>>> Lan, > >>>>> Yes, I think http2 and some new protocols such as rsocket can be > >>>>> considered. > >>>>> I will spend some time to study this issue. > >>>>> > >>>>> > >>>>> Warm regards, > >>>>> Taosheng > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ------------------ Original ------------------ > >>>>> From: Ian Luo <[email protected] <mailto:[email protected]>> > >>>>> Date: Thu,Jan 24,2019 9:58 AM > >>>>> To: dev <[email protected] <mailto:[email protected]>> > >>>>> Subject: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really > >>>>> should start it ASAP > >>>>> > >>>>> > >>>>> > >>>>> Taosheng, > >>>>> > >>>>> In this scenario, it looks like we should use http2 to transport the > >>>>> payload, what do you think? > >>>>> > >>>>> Thanks, > >>>>> -Ian. > >>>>> > >>>>> On Wed, Jan 23, 2019 at 10:35 PM Taosheng Wei < > >> [email protected] > >>> <mailto:[email protected]>> > >>>>> wrote: > >>>>> > >>>>>> I think we can find a binary protocol with strong potential to be a > >>>>> public > >>>>>> application protocol like http, and extend it with security > function. > >>> Or > >>>>> if > >>>>>> there aren't such suitable protocols, we can try to formulate a new > >>>>>> protocol. Then make Dubbo support it. > >>>>>> In my opinion, this way may not only solve the security problems, > but > >>>>> also > >>>>>> solve the cross-language RPC with Dubbo. > >>>>>> > >>>>>> [email protected] <mailto:[email protected]> < > >>> [email protected] <mailto:[email protected]>> 于2019年1月23日周三 > >>> 下午5:47写道： > >>>>>> > >>>>>>> I have a similar Question as this mail: > >>>>>>> Is Dubbo designed for use on internet? > >>>>>>> I have just join a company last year and our business is all around > >>> the > >>>>>>> world. > >>>>>>> So we have servers on US and ASIA and EU. > >>>>>>> In this condition we use dubbo on internet and keep security by > >>>>> security > >>>>>>> rules that only allow the servers connect to each other. > >>>>>>> > >>>>>>> I think this is not a pretty useage of dubbo，but I cann't find > >> Strong > >>>>>>> evidences to change the situation. > >>>>>>> > >>>>>>> Can any one help me to answer this questions? Thanks a lot. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ------------------------------ > >>>>>>> 您的朋友：刘志广 > >>>>>>> > >>>>>>> > >>>>>>> *From:* Yuhao Bi <[email protected] <mailto:[email protected]>> > >>>>>>> *Date:* 2019-01-22 22:55 > >>>>>>> *To:* dev <[email protected] <mailto:[email protected]>> > >>>>>>> *Subject:* Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we > >>> really > >>>>>>> should start it ASAP > >>>>>>> Hi lan and community, > >>>>>>> > >>>>>>> Although I have already heard "Dubbo" a few years ago, > >>>>>>> but I just started to learn dubbo after the meetup last year in > >>> Chengdu > >>>>>>> after it became the Apache Dubbo. > >>>>>>> Maybe I'm not such that familiar with the underlying details, but > >>> after > >>>>>>> the continuous participated > >>>>>>> I feel like a part of the community, and free to share my opinion. > >>>>>>> > >>>>>>> So, here is my question and also consider it my suggestion: > >>>>>>> Should we care more about Security? How can we prevent from > >>>>> unauthorized > >>>>>>> remote call? > >>>>>>> - Should we support Authentication and Authorization > >>>>>>> - Should we add Spring Security or Active Directory Service support > >> at > >>>>>> the > >>>>>>> framework level > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Yuhao > >>>>>>> > >>>>>>> > >>>>>>> jun liu <[email protected] <mailto:[email protected]>> > >>> 于2019年1月22日周二 下午5:50写道： > >>>>>>> > >>>>>>>>> I think the online integration test and performance test > >>>>> environment > >>>>>>>> should > >>>>>>>>> be set up for the new features. > >>>>>>>> > >>>>>>>> Agree! We should start as soon as possible, from 2.7.x. > >>>>>>>> > >>>>>>>> Jun > >>>>>>>> > >>>>>>>>> On Jan 22, 2019, at 5:43 PM, Xin Wang <[email protected] > >>> <mailto:[email protected]>> > >>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> I think the online integration test and performance test > >>>>> environment > >>>>>>>> should > >>>>>>>>> be set up for the new features. > >>>>>>>>> > >>>>>>>>> Ian Luo <[email protected] <mailto:[email protected]>> > >>> 于2019年1月22日周二 下午3:04写道： > >>>>>>>>> > >>>>>>>>>> Yuhao, good idea. > >>>>>>>>>> > >>>>>>>>>> BTW, do you have any thought on what Dubbo 3.0 should be? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> -Ian. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <[email protected] > >>> <mailto:[email protected]>> > >>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Once we have decided what to do in the next. > >>>>>>>>>>> Should we have a website page to publish it? e.g. [1] > >>>>>>>>>>> > >>>>>>>>>>> [1]. https://phoenix.apache.org/roadmap.html < > >>> https://phoenix.apache.org/roadmap.html> > >>>>>>>>>>> > >>>>>>>>>>> yuneng xie <[email protected] <mailto:[email protected]>> > >>> 于2019年1月22日周二 下午2:25写道： > >>>>>>>>>>> > >>>>>>>>>>>> Hi Ian Luo, > >>>>>>>>>>>> > >>>>>>>>>>>> OK, i'd start to work on it soon. > >>>>>>>>>>>> > >>>>>>>>>>>> Ian Luo <[email protected] <mailto:[email protected]>> > >>> 于2019年1月17日周四 下午2:01写道： > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Yuneng, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Sounds interesting. I am especially interested in reactive > >>>>>>>>>> programming > >>>>>>>>>>>>> support. Pls. go ahead to try implement it on 3.x branch. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> -Ian. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie < > >>>>> [email protected] <mailto:[email protected]> > >>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi folks, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I agreed with Ian Luo on the improvement list. I also got > >> some > >>>>>>> idea > >>>>>>>>>>> in > >>>>>>>>>>>> my > >>>>>>>>>>>>>> mind. I'd just share with you two points below in detail > >>>>> which > >>>>>>> i'm > >>>>>>>>>>>> most > >>>>>>>>>>>>>> interested in right now. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1. Upgrade the core abstraction "Invoker", which works in > >>>>> sync > >>>>>>>>>> mode, > >>>>>>>>>>>> to > >>>>>>>>>>>>> an > >>>>>>>>>>>>>> abstraction works in async mode. then we can construct > >>>>>>>>>>>>>> InvocationChain/FilterChain that works in async mode. A > core > >>>>>>>>>>>> abstraction > >>>>>>>>>>>>>> works in async mode would simplify the sync/async logic. We > >>>>> no > >>>>>>>>>>> longer > >>>>>>>>>>>>> need > >>>>>>>>>>>>>> to repeat the logic about sync-mode/async-mode in each > >>>>>>>>>>> ProtocolInvoker. > >>>>>>>>>>>>>> ProtocolInvoker could concentrate on async logic and we > could > >>>>>>>>>> handle > >>>>>>>>>>>>>> sync-mode invoke all in once by wrapping the > >>>>>> AsyncInvocationChain > >>>>>>>>>>> into > >>>>>>>>>>>> a > >>>>>>>>>>>>>> SyncInvocationChain. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 2. Support using stream-value (Fowable, Flux...) as > >>>>>>>>>>> param/returnType. > >>>>>>>>>>>>>> really a nice feature. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please let me known your opinion on my points. I'm also glad > >>>>> to > >>>>>>>>>> just > >>>>>>>>>>>> give > >>>>>>>>>>>>>> it a try and raise a pr. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Ian Luo <[email protected] <mailto:[email protected]>> > >>> 于2019年1月10日周四 下午6:00写道： > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi folks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Finally we managed to ramp down version 2.7.0 development, > >>>>> and > >>>>>>>>>>>>> hopefully > >>>>>>>>>>>>>> we > >>>>>>>>>>>>>>> can start the vote in the early of the next week. But the > >>>>> main > >>>>>>>>>>>> purpose > >>>>>>>>>>>>> of > >>>>>>>>>>>>>>> this email is not a release announcement. Instead, since we > >>>>> now > >>>>>>>>>>> have > >>>>>>>>>>>>>>> bandwidth, let's consider and discuss what we should focus > >>>>> out > >>>>>>>>>> from > >>>>>>>>>>>>> many > >>>>>>>>>>>>>>> stuff we want to do. For example, we may focus more on > issue > >>>>>> and > >>>>>>>>>>> pull > >>>>>>>>>>>>>>> request on GitHub, or we may plan 2.7 minor releases > >>>>>> immediately > >>>>>>>>>>>> after > >>>>>>>>>>>>> we > >>>>>>>>>>>>>>> release 2.7.0. But today I'd like to bring up one longer > >> term > >>>>>>>>>> plan > >>>>>>>>>>>>> which > >>>>>>>>>>>>>>> I'm now caring most, that is, how we define what version > 3.0 > >>>>>> is? > >>>>>>>>>>> and > >>>>>>>>>>>>> when > >>>>>>>>>>>>>>> can we get start on it? In my opinion, we need to start it > >>>>>> right > >>>>>>>>>>> from > >>>>>>>>>>>>>> this > >>>>>>>>>>>>>>> moment. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion > >>>>> on > >>>>>>>>>> the > >>>>>>>>>>>> same > >>>>>>>>>>>>>>> topic [1] in July this year. I summarize his points here if > >>>>> you > >>>>>>>>>> are > >>>>>>>>>>>> too > >>>>>>>>>>>>>>> impatient to read through the contents of his email :p: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 1. Need to enhance the current extension mechanism > >>>>>>>>>>>>>>> 2. Need to enhance the code base for better maintenance > >>>>>>>>>>>>>>> 3. Need to support async > >>>>>>>>>>>>>>> 4. Need to decouple registry server and config server > >>>>>>>>>>>>>>> 5. Need to support Java8 and above so that we can use > >>>>> advanced > >>>>>>>>>>>> features > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>>> Dubbo's core > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I agree with most of his points in this good proposal. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Here I'd like to initial a discussion on how we define > Dubbo > >>>>>> 3.0, > >>>>>>>>>>> or > >>>>>>>>>>>> in > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> other word, how do the community expect from Dubbo 3.0. In > >> my > >>>>>>>>>>>> opinion, > >>>>>>>>>>>>> I > >>>>>>>>>>>>>>> think we need to answer the following questions in this > >> major > >>>>>>>>>>>> release: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Today the boundary between messaging and remoting call > >> gets > >>>>>>>>>> blur. > >>>>>>>>>>>> We > >>>>>>>>>>>>>> may > >>>>>>>>>>>>>>> need to consider to support streaming at the protocol > level. > >>>>>>>>>>>>>>> - Reative programming and its fundamental FP start to get > >>>>>>>>>> adopted. > >>>>>>>>>>> We > >>>>>>>>>>>>>>> should consider to support it. > >>>>>>>>>>>>>>> - Dubbo should be redesigned to support async better, and > >>>>>> treats > >>>>>>>>>>>> async > >>>>>>>>>>>>> as > >>>>>>>>>>>>>>> the first class citizen. We do support async feature in > >> 2.7.0 > >>>>>>>>>>> release > >>>>>>>>>>>>> but > >>>>>>>>>>>>>>> it is not so perfect. > >>>>>>>>>>>>>>> - Micro-services has been widely adopted. How Dubbo works > >>>>>>>>>>> seamlessly > >>>>>>>>>>>>> with > >>>>>>>>>>>>>>> micro-services becomes a question mark. We need to look > into > >>>>>> the > >>>>>>>>>>>>> inter-op > >>>>>>>>>>>>>>> between Dubbo and micro-services's registry server/config > >>>>>> server. > >>>>>>>>>>> The > >>>>>>>>>>>>>>> support on separating registry server and config server in > >>>>>> 2.7.0 > >>>>>>>>>>>>> release > >>>>>>>>>>>>>> is > >>>>>>>>>>>>>>> a good start, but there are still lots of further works > >>>>>> remaining > >>>>>>>>>>>> with > >>>>>>>>>>>>> no > >>>>>>>>>>>>>>> doubt. > >>>>>>>>>>>>>>> - Once we conquer seamless micro-services support, we still > >>>>>> need > >>>>>>>>>> to > >>>>>>>>>>>>> take > >>>>>>>>>>>>>>> one step further to think about K8S integration. After all, > >>>>> K8S > >>>>>>>>>> and > >>>>>>>>>>>>>> service > >>>>>>>>>>>>>>> mesh built above it are now considered the best way for > >>>>>>>>>>>> micro-services > >>>>>>>>>>>>>>> deployment. > >>>>>>>>>>>>>>> - How we define mini-dubbo, or phrase in another way, what > >>>>> the > >>>>>>>>>>>> minimal > >>>>>>>>>>>>>>> feature set we should define for Dubbo framework. The > reason > >>>>>>>>>> behind > >>>>>>>>>>>>> this > >>>>>>>>>>>>>>> is, it is very helpful for developing more language > supports > >>>>>> from > >>>>>>>>>>> the > >>>>>>>>>>>>>>> community. This also means, we need to modularize Dubbo > >>>>>> further, > >>>>>>>>>> to > >>>>>>>>>>>>> make > >>>>>>>>>>>>>> it > >>>>>>>>>>>>>>> a reference implementation for other languages. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> In short, I suggest we need to focus on streaming protocol, > >>>>>>>>>> Rx/FP, > >>>>>>>>>>>>> native > >>>>>>>>>>>>>>> async, micro-services support, refactor/modularize areas. > Of > >>>>>>>>>>> course, > >>>>>>>>>>>>>> there > >>>>>>>>>>>>>>> are more I don't mention in this email, for examples: how > we > >>>>>> make > >>>>>>>>>>>> Dubbo > >>>>>>>>>>>>>>> more resilient? how we support HTTP/2? and more. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Pls. let me know your opinion on what I and Liujie > proposed, > >>>>>> and > >>>>>>>>>>>> share > >>>>>>>>>>>>>> your > >>>>>>>>>>>>>>> thought on what kind of features really matter to you. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> -Ian. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 1. Proposal for Dubbo 3.0 from [email protected] > >> <mailto: > >>> [email protected]> on > >>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>> > >>> > >> > >
