Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-03-07 Thread jun liu
Great! With this we would be able to support Rx programming model and Stream 
communication.

I’d like to give a review on it.

Jun

> On Mar 7, 2019, at 3:05 PM, yuneng xie  wrote:
> 
> Hi folks,
> 
> the first stage of the reative-stream support has been finished. we now can
> using Mono/Flux as return value.   i have raised a pr :
> https://github.com/apache/incubator-dubbo/pull/3609 . all code is in the
> module called dubbo-rpc-rsocket.
> 
> i would try to complete the feature so that we can use Mono/Flux as args in
> rpc.
> 
> 
> 
> 
> 
> yuneng xie  于2019年1月22日周二 下午2:25写道:
> 
>> Hi Ian Luo,
>> 
>> OK, i'd start to work on it soon.
>> 
>> Ian Luo  于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  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  于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 behi

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-03-06 Thread yuneng xie
Hi folks,

the first stage of the reative-stream support has been finished. we now can
using Mono/Flux as return value.   i have raised a pr :
https://github.com/apache/incubator-dubbo/pull/3609 . all code is in the
module called dubbo-rpc-rsocket.

i would try to complete the feature so that we can use Mono/Flux as args in
rpc.





yuneng xie  于2019年1月22日周二 下午2:25写道:

> Hi Ian Luo,
>
> OK, i'd start to work on it soon.
>
> Ian Luo  于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  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  于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 langu

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-10 Thread Ian Luo
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  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  写道:
> >
> > +1 in the suggestion.
> >
> > On Saturday, February 2, 2019, Ian Luo  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  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>> 写道:
> >>>>
> >>>> 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 mailto:ian@gmail.com>>
> >>>>> Date: Thu,Jan 24,2019 9:58 AM
> >>>>> To: dev 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_.

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-03 Thread Kun Song
I guess what Taosheng propose here is a DSL to build REST apis, DSL is good, 
confluent and concise.

> 在 2019年2月3日,下午3:24,jun liu  写道:
> 
> Hi, Taosheng
> 
>> 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
> 
> 
> Sounds pretty good, only functional bean registration is a new concept for 
> me, I will spend some time on it. Would you please help to check its possible 
> relation with the builder API in here 
> https://github.com/apache/incubator-dubbo/issues/3431?
> 
> Jun
> 
>> On Feb 3, 2019, at 12:55 AM, Taosheng, Wei  wrote:
>> 
>> 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.
> 



Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-03 Thread Kun Song
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  写道:
> 
> +1 in the suggestion.
> 
> On Saturday, February 2, 2019, Ian Luo  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  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>> 写道:
>>>> 
>>>> 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 mailto:ian@gmail.com>>
>>>>> Date: Thu,Jan 24,2019 9:58 AM
>>>>> To: dev 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
>

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-02 Thread jun liu
Hi, Taosheng

> 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


Sounds pretty good, only functional bean registration is a new concept for me, 
I will spend some time on it. Would you please help to check its possible 
relation with the builder API in here 
https://github.com/apache/incubator-dubbo/issues/3431?

Jun

> On Feb 3, 2019, at 12:55 AM, Taosheng, Wei  wrote:
> 
> 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.



Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-02 Thread Taosheng, Wei
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 
Date: Sat,Feb 2,2019 6:12 AM
To: dev 
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??2810:44??Ian Luo  <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  <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 mailto:ian....@gmail.com>>
>> Date: Thu,Jan 24,2019 9:58 AM
>> To: dev 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 > <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> >> <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 mailto:byh0...@gmail.com>>
>>>> *Date:* 2019-01-22 22:55
>>>> *To:* dev 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 m

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-02 Thread Imteyaz Khan
+1 in the suggestion.

On Saturday, February 2, 2019, Ian Luo  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  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>> 写道:
> > >
> > > 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 mailto:ian@gmail.com>>
> > >> Date: Thu,Jan 24,2019 9:58 AM
> > >> To: dev 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.
> > >>>>
> > >>>>
> > >>>>
> > >>>> 

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-02 Thread Ian Luo
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  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>> 写道:
> >
> > Agree, we should consider seriously both HTTP/2 and rsocket.
> >
> > Thanks,
> > -Ian.
> >
> >
> > On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei  <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 mailto:ian@gmail.com>>
> >> Date: Thu,Jan 24,2019 9:58 AM
> >> To: dev 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  <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 mailto:byh0...@gmail.com>>
> >>>> *Date:* 2019-01-22 22:55
> >>>> *To:* dev 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
> >>>> a

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-01 Thread Huxing Zhang
Hi,

On Sat, Feb 2, 2019 at 6:12 AM Kun Song  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.

Good suggestion. +1 for the feature proposal.

>
>
> [1] http://www.reactive-streams.org/ <http://www.reactive-streams.org/>
>
> > 在 2019年1月28日,下午10:44,Ian Luo 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  > <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 mailto:ian@gmail.com>>
> >> Date: Thu,Jan 24,2019 9:58 AM
> >> To: dev mailto:dev@dubbo.apache.org>>
> >> Subject: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really
> >> should start it ASAP
> >>
> >>

> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
>


-- 
Best Regards!
Huxing


Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-01 Thread Kun Song
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 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  <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 mailto:ian....@gmail.com>>
>> Date: Thu,Jan 24,2019 9:58 AM
>> To: dev 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 > <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> >> <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 mailto:byh0...@gmail.com>>
>>>> *Date:* 2019-01-22 22:55
>>>> *To:* dev 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
>>>> fram

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-02-01 Thread Kun Song
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 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  <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 mailto:ian....@gmail.com>>
>> Date: Thu,Jan 24,2019 9:58 AM
>> To: dev 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 > <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> >> <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 mailto:byh0...@gmail.com>>
>>>> *Date:* 2019-01-22 22:55
>>>> *To:* dev 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
>>>> fram

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-28 Thread Ian Luo
Agree, we should consider seriously both HTTP/2 and rsocket.

Thanks,
-Ian.


On Thu, Jan 24, 2019 at 10:59 AM Taosheng, Wei 
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 
> Date: Thu,Jan 24,2019 9:58 AM
> To: dev 
> 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 
> 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  于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 
> > > *Date:* 2019-01-22 22:55
> > > *To:* dev 
> > > *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  于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 
> > > wrote:
> > > > >
> > > > > I think the online integration test and performance test
> environment
> > > > should
> > > > > be set up for the new features.
> > > > >
> > > > > Ian Luo  于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 
> 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  于2019年1月22日周二 下午2:2

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-23 Thread Taosheng, Wei
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 
Date: Thu,Jan 24,2019 9:58 AM
To: dev 
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 
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  ??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 
> > *Date:* 2019-01-22 22:55
> > *To:* dev 
> > *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  ??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 
> > wrote:
> > > >
> > > > I think the online integration test and performance test environment
> > > should
> > > > be set up for the new features.
> > > >
> > > > Ian Luo  ??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  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  ??2019??1??22?? 2:25??
> > > >>>
> > > >>>> Hi Ian Luo,
> > > >>>>
> > > >>>> OK, i'd start to work on it soon.
> > > >>>>
> > > >>>> Ian Luo  ??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.
> > > >>>>>
> > > >>>

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-23 Thread jun liu
Hi Zhiguang,

> In this condition we use dubbo on internet and keep security by security 
> rules that only allow the servers connect to each other.

I want to know how do you apply the security rules to Dubbo. Can you provide 
more detail on this?

Jun

> On Jan 23, 2019, at 5:47 PM, zhi_guang_...@163.com wrote:
> 
> 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 <mailto:byh0...@gmail.com>
> Date: 2019-01-22 22:55
> To: dev <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  于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  wrote:
> > >
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> > >
> > > Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
> > >>>
> > >>>> Hi Ian Luo,
> > >>>>
> > >>>> OK, i'd start to work on it soon.
> > >>>>
> > >>>> Ian Luo  于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 
> > >>> 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 s

Re: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

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

Re: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-23 Thread Taosheng Wei
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  于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 
> *Date:* 2019-01-22 22:55
> *To:* dev 
> *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  于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 
> wrote:
> > >
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> > >
> > > Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
> > >>>
> > >>>> Hi Ian Luo,
> > >>>>
> > >>>> OK, i'd start to work on it soon.
> > >>>>
> > >>>> Ian Luo  于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 
> > >>> 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
> > >>>&

Re: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-23 Thread Ian Luo
If the RT is acceptable between the data center, this usage is perfectly
fine.

-Ian.

On Wed, Jan 23, 2019 at 5:47 PM zhi_guang_...@163.com 
wrote:

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

Re: Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-23 Thread zhi_guang_...@163.com
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
Date: 2019-01-22 22:55
To: dev
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  于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  wrote:
> >
> > I think the online integration test and performance test environment
> should
> > be set up for the new features.
> >
> > Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
> >>>
> >>>> Hi Ian Luo,
> >>>>
> >>>> OK, i'd start to work on it soon.
> >>>>
> >>>> Ian Luo  于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 
> >>> 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.
> >&g

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-22 Thread Xin Wang
>  - Reative programming and its fundamental FP start to get adopted. We
should consider to support it.

It looks like we're thinking about "full stack asynchronization" , I think
the Spring4 shoud be upgraded to spring5

Although Spring is an optional component in Dubbo,  but spring 5 provides
some asynchronous features, such as webFlux,
 which integrates Rxjava

Here is the 《Upgrading to Spring Framework 5.x》[1] , I translated it
Chinese and wrote some opinions  of my own [2].

[1]
https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-5.x
[2] http://lovepoem.github.io/2018/09/05/framework/spring5_new_features/

Ian Luo  于2019年1月23日周三 上午11:11写道:

> Thanks for Yuhao raising this good point. In my opinion, both ACL and
> transaction are important to Dubbo, and the community keep demanding the
> support on these areas. We should put them in our roadmap.
>
> Thanks,
> -Ian.
>
>
> On Tue, Jan 22, 2019 at 10:55 PM Yuhao Bi  wrote:
>
> > 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  于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 
> > wrote:
> > > >
> > > > I think the online integration test and performance test environment
> > > should
> > > > be set up for the new features.
> > > >
> > > > Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
> > > >>>
> > >  Hi Ian Luo,
> > > 
> > >  OK, i'd start to work on it soon.
> > > 
> > >  Ian Luo  于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  >
> > > >>> 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  于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
> > > >>> bandw

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-22 Thread Ian Luo
Thanks for Yuhao raising this good point. In my opinion, both ACL and
transaction are important to Dubbo, and the community keep demanding the
support on these areas. We should put them in our roadmap.

Thanks,
-Ian.


On Tue, Jan 22, 2019 at 10:55 PM Yuhao Bi  wrote:

> 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  于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 
> wrote:
> > >
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> > >
> > > Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
> > >>>
> >  Hi Ian Luo,
> > 
> >  OK, i'd start to work on it soon.
> > 
> >  Ian Luo  于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 
> > >>> 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  于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

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-22 Thread Yuhao Bi
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  于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  wrote:
> >
> > I think the online integration test and performance test environment
> should
> > be set up for the new features.
> >
> > Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
> >>>
>  Hi Ian Luo,
> 
>  OK, i'd start to work on it soon.
> 
>  Ian Luo  于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 
> >>> 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  于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,
> >>

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-22 Thread jun liu
> 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  wrote:
> 
> I think the online integration test and performance test environment should
> be set up for the new features.
> 
> Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
>>> 
 Hi Ian Luo,
 
 OK, i'd start to work on it soon.
 
 Ian Luo  于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 
>>> 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  于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

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-22 Thread Xin Wang
I think the online integration test and performance test environment should
be set up for the new features.

Ian Luo  于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  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  于2019年1月22日周二 下午2:25写道:
> >
> > > Hi Ian Luo,
> > >
> > > OK, i'd start to work on it soon.
> > >
> > > Ian Luo  于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 
> > 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  于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 

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-21 Thread Ian Luo
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  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  于2019年1月22日周二 下午2:25写道:
>
> > Hi Ian Luo,
> >
> > OK, i'd start to work on it soon.
> >
> > Ian Luo  于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 
> 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  于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.
> > >

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-21 Thread Yuhao Bi
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  于2019年1月22日周二 下午2:25写道:

> Hi Ian Luo,
>
> OK, i'd start to work on it soon.
>
> Ian Luo  于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  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  于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 o

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-21 Thread yuneng xie
Hi Ian Luo,

OK, i'd start to work on it soon.

Ian Luo  于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  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  于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

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-16 Thread Ian Luo
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  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  于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 on
> > dev@dubbo.apache.org
> >
>


Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-16 Thread yuneng xie
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  于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 on
> dev@dubbo.apache.org
>


Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

2019-01-14 Thread Huxing Zhang
What I am thinking about the next generation of Dubbo should be:

- cloud native: should be well integrated into Kubernetes, and Dubbo
protocol should be seamlessly go through service mesh sidecar like
Envoy.
- reactive: should keep the RPC invocation completely reactive
- polyglot: Dubbo service should be invoked across different languages.

The features I think Dubbo should have(maybe in 2.7):

- Integration with other microservice components, like API gateway,
monitoring and distributed tracing, distributed transaction,
scheduling, and etc.
- the Dubbo modules should be separated from the framework and can be
used as standalone dependency. For example, the load balancing module
can be separated as a library and used by other projects
- Integration with standards, like HTTP/2 support. This is important
because if we support HTTP/2, it will be easier to integrate with
other microservice components that supports HTTP/2.

On Thu, Jan 10, 2019 at 6:00 PM Ian Luo  wrote:
>
> 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 on dev@dubbo.apache.org



-- 
Best Regards!
Huxing