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 <khan.imte...@gmail.com> 写道： > > +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> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>> >>> >>
