+1 in the suggestion. On Saturday, February 2, 2019, Ian Luo <ian....@gmail.com> 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 <songkun...@gmail.com> 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 <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 < > 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 <ian....@gmail.com <mailto:ian....@gmail.com>> > > >> Date: Thu,Jan 24,2019 9:58 AM > > >> To: dev <dev@dubbo.apache.org <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. > > >>>> > > >>>> > > >>>> > > >>>> ------------------------------ > > >>>> 您的朋友：刘志广 > > >>>> > > >>>> > > >>>> *From:* Yuhao Bi <byh0...@gmail.com <mailto:byh0...@gmail.com>> > > >>>> *Date:* 2019-01-22 22:55 > > >>>> *To:* dev <dev@dubbo.apache.org <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 <ken.lj...@gmail.com <mailto:ken.lj...@gmail.com>> > > 于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 <xin.victorw...@gmail.com > > <mailto:xin.victorw...@gmail.com>> > > >>>> wrote: > > >>>>>> > > >>>>>> I think the online integration test and performance test > > >> environment > > >>>>> should > > >>>>>> be set up for the new features. > > >>>>>> > > >>>>>> Ian Luo <ian....@gmail.com <mailto:ian....@gmail.com>> > > 于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 <byh0...@gmail.com > > <mailto:byh0...@gmail.com>> > > >> 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 <xieyun...@gmail.com <mailto:xieyun...@gmail.com>> > > 于2019年1月22日周二 下午2:25写道： > > >>>>>>>> > > >>>>>>>>> Hi Ian Luo, > > >>>>>>>>> > > >>>>>>>>> OK, i'd start to work on it soon. > > >>>>>>>>> > > >>>>>>>>> Ian Luo <ian....@gmail.com <mailto:ian....@gmail.com>> > > 于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 < > > >> xieyun...@gmail.com <mailto:xieyun...@gmail.com> > > >>>> > > >>>>>>>> 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 <ian....@gmail.com <mailto:ian....@gmail.com>> > > 于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 > <mailto: > > liujie...@apache.org> on > > >>>>>>>>>>>> dev@dubbo.apache.org <mailto:dev@dubbo.apache.org> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > > > >
