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]> 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]> > Date: Thu,Jan 24,2019 9:58 AM > To: dev <[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]> > 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] <[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]> > > > *Date:* 2019-01-22 22:55 > > > *To:* dev <[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]> 于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]> > > > wrote: > > > > > > > > > > I think the online integration test and performance test > environment > > > > should > > > > > be set up for the new features. > > > > > > > > > > Ian Luo <[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]> > 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 <[email protected]> 于2019年1月22日周二 下午2:25写道： > > > > >>> > > > > >>>> Hi Ian Luo, > > > > >>>> > > > > >>>> OK, i'd start to work on it soon. > > > > >>>> > > > > >>>> Ian Luo <[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] > > > > > > > >>> 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]> 于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] on > > > > >>>>>>> [email protected] > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > > > >
