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 <songkun...@gmail.com> Date: Sat,Feb 2,2019 6:12 AM To: dev <dev@dubbo.apache.org> 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??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> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>>
