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

[Ian Luo <ia...@gmail.com>]

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 liujieqin@apache.org on dev@dubbo.apache.org

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

[Huxing Zhang <hu...@apache.org>]

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 <ia...@gmail.com> 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 liujieqin@apache.org on dev@dubbo.apache.org



-- 
Best Regards！
Huxing

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

[Xin Wang <xi...@gmail.com>]

>  - 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 <ia...@gmail.com> 于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 <by...@gmail.com> 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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：
> >
> > > > I think the online integration test and performance test environment
> > > should
> > > > be set up for the new features.
> > >
> > > Agree!  We should start as soon as possible, from 2.7.x.
> > >
> > > Jun
> > >
> > > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com>
> > wrote:
> > > >
> > > > I think the online integration test and performance test environment
> > > should
> > > > be set up for the new features.
> > > >
> > > > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> > > >
> > > >> Yuhao, good idea.
> > > >>
> > > >> BTW, do you have any thought on what Dubbo 3.0 should be?
> > > >>
> > > >> Thanks,
> > > >> -Ian.
> > > >>
> > > >>
> > > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> > > >>
> > > >>> Once we have decided what to do in the next.
> > > >>> Should we have a website page to publish it? e.g. [1]
> > > >>>
> > > >>> [1]. https://phoenix.apache.org/roadmap.html
> > > >>>
> > > >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> > > >>>
> > > >>>> Hi Ian Luo,
> > > >>>>
> > > >>>> OK, i'd start to work on it soon.
> > > >>>>
> > > >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> > > >>>>
> > > >>>>> Hi Yuneng,
> > > >>>>>
> > > >>>>> Sounds interesting. I am especially interested in reactive
> > > >> programming
> > > >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> -Ian.
> > > >>>>>
> > > >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xieyuneng@gmail.com
> >
> > > >>> wrote:
> > > >>>>>
> > > >>>>>> Hi folks,
> > > >>>>>>
> > > >>>>>> I agreed with Ian Luo on the improvement list. I also got some
> > idea
> > > >>> in
> > > >>>> my
> > > >>>>>> mind.  I'd just share with you two points below in detail which
> > i'm
> > > >>>> most
> > > >>>>>> interested in right now.
> > > >>>>>>
> > > >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> > > >> mode,
> > > >>>> to
> > > >>>>> an
> > > >>>>>> abstraction works in async mode. then we can construct
> > > >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> > > >>>> abstraction
> > > >>>>>> works in async mode would simplify the sync/async logic. We  no
> > > >>> longer
> > > >>>>> need
> > > >>>>>> to repeat the logic about sync-mode/async-mode in each
> > > >>> ProtocolInvoker.
> > > >>>>>> ProtocolInvoker could concentrate on async logic and we could
> > > >> handle
> > > >>>>>> sync-mode invoke all in once by wrapping the
> AsyncInvocationChain
> > > >>> into
> > > >>>> a
> > > >>>>>> SyncInvocationChain.
> > > >>>>>>
> > > >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> > > >>> param/returnType.
> > > >>>>>> really a nice feature.
> > > >>>>>>
> > > >>>>>> Please let me known your opinion on my points. I'm also glad to
> > > >> just
> > > >>>> give
> > > >>>>>> it a try and raise a pr.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > > >>>>>>
> > > >>>>>>> Hi folks,
> > > >>>>>>>
> > > >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> > > >>>>> hopefully
> > > >>>>>> we
> > > >>>>>>> can start the vote in the early of the next week. But the main
> > > >>>> purpose
> > > >>>>> of
> > > >>>>>>> this email is not a release announcement. Instead, since we now
> > > >>> have
> > > >>>>>>> bandwidth, let's consider and discuss what we should focus out
> > > >> from
> > > >>>>> many
> > > >>>>>>> stuff we want to do. For example, we may focus more on issue
> and
> > > >>> pull
> > > >>>>>>> request on GitHub, or we may plan 2.7 minor releases
> immediately
> > > >>>> after
> > > >>>>> we
> > > >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> > > >> plan
> > > >>>>> which
> > > >>>>>>> I'm now caring most, that is, how we define what version 3.0
> is?
> > > >>> and
> > > >>>>> when
> > > >>>>>>> can we get start on it? In my opinion, we need to start it
> right
> > > >>> from
> > > >>>>>> this
> > > >>>>>>> moment.
> > > >>>>>>>
> > > >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> > > >> the
> > > >>>> same
> > > >>>>>>> topic [1] in July this year. I summarize his points here if you
> > > >> are
> > > >>>> too
> > > >>>>>>> impatient to read through the contents of his email :p:
> > > >>>>>>>
> > > >>>>>>> 1. Need to enhance the current extension mechanism
> > > >>>>>>> 2. Need to enhance the code base for better maintenance
> > > >>>>>>> 3. Need to support async
> > > >>>>>>> 4. Need to decouple registry server and config server
> > > >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> > > >>>> features
> > > >>>>>> in
> > > >>>>>>> Dubbo's core
> > > >>>>>>>
> > > >>>>>>> I agree with most of his points in this good proposal.
> > > >>>>>>>
> > > >>>>>>> Here I'd like to initial a discussion on how we define Dubbo
> 3.0,
> > > >>> or
> > > >>>> in
> > > >>>>>> the
> > > >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> > > >>>> opinion,
> > > >>>>> I
> > > >>>>>>> think we need to answer the following questions in this major
> > > >>>> release:
> > > >>>>>>>
> > > >>>>>>> - Today the boundary between messaging and remoting call gets
> > > >> blur.
> > > >>>> We
> > > >>>>>> may
> > > >>>>>>> need to consider to support streaming at the protocol level.
> > > >>>>>>> - Reative programming and its fundamental FP start to get
> > > >> adopted.
> > > >>> We
> > > >>>>>>> should consider to support it.
> > > >>>>>>> - Dubbo should be redesigned to support async better, and
> treats
> > > >>>> async
> > > >>>>> as
> > > >>>>>>> the first class citizen. We do support async feature in 2.7.0
> > > >>> release
> > > >>>>> but
> > > >>>>>>> it is not so perfect.
> > > >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> > > >>> seamlessly
> > > >>>>> with
> > > >>>>>>> micro-services becomes a question mark. We need to look into
> the
> > > >>>>> inter-op
> > > >>>>>>> between Dubbo and micro-services's registry server/config
> server.
> > > >>> The
> > > >>>>>>> support on separating registry server and config server in
> 2.7.0
> > > >>>>> release
> > > >>>>>> is
> > > >>>>>>> a good start, but there are still lots of further works
> remaining
> > > >>>> with
> > > >>>>> no
> > > >>>>>>> doubt.
> > > >>>>>>> - Once we conquer seamless micro-services support, we still
> need
> > > >> to
> > > >>>>> take
> > > >>>>>>> one step further to think about K8S integration. After all, K8S
> > > >> and
> > > >>>>>> service
> > > >>>>>>> mesh built above it are now considered the best way for
> > > >>>> micro-services
> > > >>>>>>> deployment.
> > > >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> > > >>>> minimal
> > > >>>>>>> feature set we should define for Dubbo framework. The reason
> > > >> behind
> > > >>>>> this
> > > >>>>>>> is, it is very helpful for developing more language supports
> from
> > > >>> the
> > > >>>>>>> community. This also means, we need to modularize Dubbo
> further,
> > > >> to
> > > >>>>> make
> > > >>>>>> it
> > > >>>>>>> a reference implementation for other languages.
> > > >>>>>>>
> > > >>>>>>> In short, I suggest we need to focus on streaming protocol,
> > > >> Rx/FP,
> > > >>>>> native
> > > >>>>>>> async, micro-services support, refactor/modularize areas. Of
> > > >>> course,
> > > >>>>>> there
> > > >>>>>>> are more I don't mention in this email, for examples: how we
> make
> > > >>>> Dubbo
> > > >>>>>>> more resilient? how we support HTTP/2? and more.
> > > >>>>>>>
> > > >>>>>>> Pls. let me know your opinion on what I and Liujie proposed,
> and
> > > >>>> share
> > > >>>>>> your
> > > >>>>>>> thought on what kind of features really matter to you.
> > > >>>>>>>
> > > >>>>>>> Thanks,
> > > >>>>>>> -Ian.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > > >>>>>>> dev@dubbo.apache.org
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

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

[Ian Luo <ia...@gmail.com>]

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 <by...@gmail.com> 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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：
>
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> >
> > Agree!  We should start as soon as possible, from 2.7.x.
> >
> > Jun
> >
> > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com>
> wrote:
> > >
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> > >
> > > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> > >
> > >> Yuhao, good idea.
> > >>
> > >> BTW, do you have any thought on what Dubbo 3.0 should be?
> > >>
> > >> Thanks,
> > >> -Ian.
> > >>
> > >>
> > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> > >>
> > >>> Once we have decided what to do in the next.
> > >>> Should we have a website page to publish it? e.g. [1]
> > >>>
> > >>> [1]. https://phoenix.apache.org/roadmap.html
> > >>>
> > >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> > >>>
> > >>>> Hi Ian Luo,
> > >>>>
> > >>>> OK, i'd start to work on it soon.
> > >>>>
> > >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> > >>>>
> > >>>>> Hi Yuneng,
> > >>>>>
> > >>>>> Sounds interesting. I am especially interested in reactive
> > >> programming
> > >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Ian.
> > >>>>>
> > >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> > >>> wrote:
> > >>>>>
> > >>>>>> Hi folks,
> > >>>>>>
> > >>>>>> I agreed with Ian Luo on the improvement list. I also got some
> idea
> > >>> in
> > >>>> my
> > >>>>>> mind.  I'd just share with you two points below in detail which
> i'm
> > >>>> most
> > >>>>>> interested in right now.
> > >>>>>>
> > >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> > >> mode,
> > >>>> to
> > >>>>> an
> > >>>>>> abstraction works in async mode. then we can construct
> > >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> > >>>> abstraction
> > >>>>>> works in async mode would simplify the sync/async logic. We  no
> > >>> longer
> > >>>>> need
> > >>>>>> to repeat the logic about sync-mode/async-mode in each
> > >>> ProtocolInvoker.
> > >>>>>> ProtocolInvoker could concentrate on async logic and we could
> > >> handle
> > >>>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain
> > >>> into
> > >>>> a
> > >>>>>> SyncInvocationChain.
> > >>>>>>
> > >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> > >>> param/returnType.
> > >>>>>> really a nice feature.
> > >>>>>>
> > >>>>>> Please let me known your opinion on my points. I'm also glad to
> > >> just
> > >>>> give
> > >>>>>> it a try and raise a pr.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > >>>>>>
> > >>>>>>> Hi folks,
> > >>>>>>>
> > >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> > >>>>> hopefully
> > >>>>>> we
> > >>>>>>> can start the vote in the early of the next week. But the main
> > >>>> purpose
> > >>>>> of
> > >>>>>>> this email is not a release announcement. Instead, since we now
> > >>> have
> > >>>>>>> bandwidth, let's consider and discuss what we should focus out
> > >> from
> > >>>>> many
> > >>>>>>> stuff we want to do. For example, we may focus more on issue and
> > >>> pull
> > >>>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
> > >>>> after
> > >>>>> we
> > >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> > >> plan
> > >>>>> which
> > >>>>>>> I'm now caring most, that is, how we define what version 3.0 is?
> > >>> and
> > >>>>> when
> > >>>>>>> can we get start on it? In my opinion, we need to start it right
> > >>> from
> > >>>>>> this
> > >>>>>>> moment.
> > >>>>>>>
> > >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> > >> the
> > >>>> same
> > >>>>>>> topic [1] in July this year. I summarize his points here if you
> > >> are
> > >>>> too
> > >>>>>>> impatient to read through the contents of his email :p:
> > >>>>>>>
> > >>>>>>> 1. Need to enhance the current extension mechanism
> > >>>>>>> 2. Need to enhance the code base for better maintenance
> > >>>>>>> 3. Need to support async
> > >>>>>>> 4. Need to decouple registry server and config server
> > >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> > >>>> features
> > >>>>>> in
> > >>>>>>> Dubbo's core
> > >>>>>>>
> > >>>>>>> I agree with most of his points in this good proposal.
> > >>>>>>>
> > >>>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0,
> > >>> or
> > >>>> in
> > >>>>>> the
> > >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> > >>>> opinion,
> > >>>>> I
> > >>>>>>> think we need to answer the following questions in this major
> > >>>> release:
> > >>>>>>>
> > >>>>>>> - Today the boundary between messaging and remoting call gets
> > >> blur.
> > >>>> We
> > >>>>>> may
> > >>>>>>> need to consider to support streaming at the protocol level.
> > >>>>>>> - Reative programming and its fundamental FP start to get
> > >> adopted.
> > >>> We
> > >>>>>>> should consider to support it.
> > >>>>>>> - Dubbo should be redesigned to support async better, and treats
> > >>>> async
> > >>>>> as
> > >>>>>>> the first class citizen. We do support async feature in 2.7.0
> > >>> release
> > >>>>> but
> > >>>>>>> it is not so perfect.
> > >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> > >>> seamlessly
> > >>>>> with
> > >>>>>>> micro-services becomes a question mark. We need to look into the
> > >>>>> inter-op
> > >>>>>>> between Dubbo and micro-services's registry server/config server.
> > >>> The
> > >>>>>>> support on separating registry server and config server in 2.7.0
> > >>>>> release
> > >>>>>> is
> > >>>>>>> a good start, but there are still lots of further works remaining
> > >>>> with
> > >>>>> no
> > >>>>>>> doubt.
> > >>>>>>> - Once we conquer seamless micro-services support, we still need
> > >> to
> > >>>>> take
> > >>>>>>> one step further to think about K8S integration. After all, K8S
> > >> and
> > >>>>>> service
> > >>>>>>> mesh built above it are now considered the best way for
> > >>>> micro-services
> > >>>>>>> deployment.
> > >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> > >>>> minimal
> > >>>>>>> feature set we should define for Dubbo framework. The reason
> > >> behind
> > >>>>> this
> > >>>>>>> is, it is very helpful for developing more language supports from
> > >>> the
> > >>>>>>> community. This also means, we need to modularize Dubbo further,
> > >> to
> > >>>>> make
> > >>>>>> it
> > >>>>>>> a reference implementation for other languages.
> > >>>>>>>
> > >>>>>>> In short, I suggest we need to focus on streaming protocol,
> > >> Rx/FP,
> > >>>>> native
> > >>>>>>> async, micro-services support, refactor/modularize areas. Of
> > >>> course,
> > >>>>>> there
> > >>>>>>> are more I don't mention in this email, for examples: how we make
> > >>>> Dubbo
> > >>>>>>> more resilient? how we support HTTP/2? and more.
> > >>>>>>>
> > >>>>>>> Pls. let me know your opinion on what I and Liujie proposed, and
> > >>>> share
> > >>>>>> your
> > >>>>>>> thought on what kind of features really matter to you.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> -Ian.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > >>>>>>> dev@dubbo.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

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

[Ian Luo <ia...@gmail.com>]

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 <ts...@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_liu@163.com <zh...@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 <by...@gmail.com>
> > *Date:* 2019-01-22 22:55
> > *To:* dev <de...@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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：
> >
> > > > I think the online integration test and performance test environment
> > > should
> > > > be set up for the new features.
> > >
> > > Agree!  We should start as soon as possible, from 2.7.x.
> > >
> > > Jun
> > >
> > > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com>
> > wrote:
> > > >
> > > > I think the online integration test and performance test environment
> > > should
> > > > be set up for the new features.
> > > >
> > > > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> > > >
> > > >> Yuhao, good idea.
> > > >>
> > > >> BTW, do you have any thought on what Dubbo 3.0 should be?
> > > >>
> > > >> Thanks,
> > > >> -Ian.
> > > >>
> > > >>
> > > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> > > >>
> > > >>> Once we have decided what to do in the next.
> > > >>> Should we have a website page to publish it? e.g. [1]
> > > >>>
> > > >>> [1]. https://phoenix.apache.org/roadmap.html
> > > >>>
> > > >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> > > >>>
> > > >>>> Hi Ian Luo,
> > > >>>>
> > > >>>> OK, i'd start to work on it soon.
> > > >>>>
> > > >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> > > >>>>
> > > >>>>> Hi Yuneng,
> > > >>>>>
> > > >>>>> Sounds interesting. I am especially interested in reactive
> > > >> programming
> > > >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> -Ian.
> > > >>>>>
> > > >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xieyuneng@gmail.com
> >
> > > >>> wrote:
> > > >>>>>
> > > >>>>>> Hi folks,
> > > >>>>>>
> > > >>>>>> I agreed with Ian Luo on the improvement list. I also got some
> > idea
> > > >>> in
> > > >>>> my
> > > >>>>>> mind.  I'd just share with you two points below in detail which
> > i'm
> > > >>>> most
> > > >>>>>> interested in right now.
> > > >>>>>>
> > > >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> > > >> mode,
> > > >>>> to
> > > >>>>> an
> > > >>>>>> abstraction works in async mode. then we can construct
> > > >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> > > >>>> abstraction
> > > >>>>>> works in async mode would simplify the sync/async logic. We  no
> > > >>> longer
> > > >>>>> need
> > > >>>>>> to repeat the logic about sync-mode/async-mode in each
> > > >>> ProtocolInvoker.
> > > >>>>>> ProtocolInvoker could concentrate on async logic and we could
> > > >> handle
> > > >>>>>> sync-mode invoke all in once by wrapping the
> AsyncInvocationChain
> > > >>> into
> > > >>>> a
> > > >>>>>> SyncInvocationChain.
> > > >>>>>>
> > > >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> > > >>> param/returnType.
> > > >>>>>> really a nice feature.
> > > >>>>>>
> > > >>>>>> Please let me known your opinion on my points. I'm also glad to
> > > >> just
> > > >>>> give
> > > >>>>>> it a try and raise a pr.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > > >>>>>>
> > > >>>>>>> Hi folks,
> > > >>>>>>>
> > > >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> > > >>>>> hopefully
> > > >>>>>> we
> > > >>>>>>> can start the vote in the early of the next week. But the main
> > > >>>> purpose
> > > >>>>> of
> > > >>>>>>> this email is not a release announcement. Instead, since we now
> > > >>> have
> > > >>>>>>> bandwidth, let's consider and discuss what we should focus out
> > > >> from
> > > >>>>> many
> > > >>>>>>> stuff we want to do. For example, we may focus more on issue
> and
> > > >>> pull
> > > >>>>>>> request on GitHub, or we may plan 2.7 minor releases
> immediately
> > > >>>> after
> > > >>>>> we
> > > >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> > > >> plan
> > > >>>>> which
> > > >>>>>>> I'm now caring most, that is, how we define what version 3.0
> is?
> > > >>> and
> > > >>>>> when
> > > >>>>>>> can we get start on it? In my opinion, we need to start it
> right
> > > >>> from
> > > >>>>>> this
> > > >>>>>>> moment.
> > > >>>>>>>
> > > >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> > > >> the
> > > >>>> same
> > > >>>>>>> topic [1] in July this year. I summarize his points here if you
> > > >> are
> > > >>>> too
> > > >>>>>>> impatient to read through the contents of his email :p:
> > > >>>>>>>
> > > >>>>>>> 1. Need to enhance the current extension mechanism
> > > >>>>>>> 2. Need to enhance the code base for better maintenance
> > > >>>>>>> 3. Need to support async
> > > >>>>>>> 4. Need to decouple registry server and config server
> > > >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> > > >>>> features
> > > >>>>>> in
> > > >>>>>>> Dubbo's core
> > > >>>>>>>
> > > >>>>>>> I agree with most of his points in this good proposal.
> > > >>>>>>>
> > > >>>>>>> Here I'd like to initial a discussion on how we define Dubbo
> 3.0,
> > > >>> or
> > > >>>> in
> > > >>>>>> the
> > > >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> > > >>>> opinion,
> > > >>>>> I
> > > >>>>>>> think we need to answer the following questions in this major
> > > >>>> release:
> > > >>>>>>>
> > > >>>>>>> - Today the boundary between messaging and remoting call gets
> > > >> blur.
> > > >>>> We
> > > >>>>>> may
> > > >>>>>>> need to consider to support streaming at the protocol level.
> > > >>>>>>> - Reative programming and its fundamental FP start to get
> > > >> adopted.
> > > >>> We
> > > >>>>>>> should consider to support it.
> > > >>>>>>> - Dubbo should be redesigned to support async better, and
> treats
> > > >>>> async
> > > >>>>> as
> > > >>>>>>> the first class citizen. We do support async feature in 2.7.0
> > > >>> release
> > > >>>>> but
> > > >>>>>>> it is not so perfect.
> > > >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> > > >>> seamlessly
> > > >>>>> with
> > > >>>>>>> micro-services becomes a question mark. We need to look into
> the
> > > >>>>> inter-op
> > > >>>>>>> between Dubbo and micro-services's registry server/config
> server.
> > > >>> The
> > > >>>>>>> support on separating registry server and config server in
> 2.7.0
> > > >>>>> release
> > > >>>>>> is
> > > >>>>>>> a good start, but there are still lots of further works
> remaining
> > > >>>> with
> > > >>>>> no
> > > >>>>>>> doubt.
> > > >>>>>>> - Once we conquer seamless micro-services support, we still
> need
> > > >> to
> > > >>>>> take
> > > >>>>>>> one step further to think about K8S integration. After all, K8S
> > > >> and
> > > >>>>>> service
> > > >>>>>>> mesh built above it are now considered the best way for
> > > >>>> micro-services
> > > >>>>>>> deployment.
> > > >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> > > >>>> minimal
> > > >>>>>>> feature set we should define for Dubbo framework. The reason
> > > >> behind
> > > >>>>> this
> > > >>>>>>> is, it is very helpful for developing more language supports
> from
> > > >>> the
> > > >>>>>>> community. This also means, we need to modularize Dubbo
> further,
> > > >> to
> > > >>>>> make
> > > >>>>>> it
> > > >>>>>>> a reference implementation for other languages.
> > > >>>>>>>
> > > >>>>>>> In short, I suggest we need to focus on streaming protocol,
> > > >> Rx/FP,
> > > >>>>> native
> > > >>>>>>> async, micro-services support, refactor/modularize areas. Of
> > > >>> course,
> > > >>>>>> there
> > > >>>>>>> are more I don't mention in this email, for examples: how we
> make
> > > >>>> Dubbo
> > > >>>>>>> more resilient? how we support HTTP/2? and more.
> > > >>>>>>>
> > > >>>>>>> Pls. let me know your opinion on what I and Liujie proposed,
> and
> > > >>>> share
> > > >>>>>> your
> > > >>>>>>> thought on what kind of features really matter to you.
> > > >>>>>>>
> > > >>>>>>> Thanks,
> > > >>>>>>> -Ian.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > > >>>>>>> dev@dubbo.apache.org
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
> >
>

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

[Taosheng Wei <ts...@apache.org>]

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_liu@163.com <zh...@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 <by...@gmail.com>
> *Date:* 2019-01-22 22:55
> *To:* dev <de...@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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：
>
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> >
> > Agree!  We should start as soon as possible, from 2.7.x.
> >
> > Jun
> >
> > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com>
> wrote:
> > >
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> > >
> > > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> > >
> > >> Yuhao, good idea.
> > >>
> > >> BTW, do you have any thought on what Dubbo 3.0 should be?
> > >>
> > >> Thanks,
> > >> -Ian.
> > >>
> > >>
> > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> > >>
> > >>> Once we have decided what to do in the next.
> > >>> Should we have a website page to publish it? e.g. [1]
> > >>>
> > >>> [1]. https://phoenix.apache.org/roadmap.html
> > >>>
> > >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> > >>>
> > >>>> Hi Ian Luo,
> > >>>>
> > >>>> OK, i'd start to work on it soon.
> > >>>>
> > >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> > >>>>
> > >>>>> Hi Yuneng,
> > >>>>>
> > >>>>> Sounds interesting. I am especially interested in reactive
> > >> programming
> > >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Ian.
> > >>>>>
> > >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> > >>> wrote:
> > >>>>>
> > >>>>>> Hi folks,
> > >>>>>>
> > >>>>>> I agreed with Ian Luo on the improvement list. I also got some
> idea
> > >>> in
> > >>>> my
> > >>>>>> mind.  I'd just share with you two points below in detail which
> i'm
> > >>>> most
> > >>>>>> interested in right now.
> > >>>>>>
> > >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> > >> mode,
> > >>>> to
> > >>>>> an
> > >>>>>> abstraction works in async mode. then we can construct
> > >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> > >>>> abstraction
> > >>>>>> works in async mode would simplify the sync/async logic. We  no
> > >>> longer
> > >>>>> need
> > >>>>>> to repeat the logic about sync-mode/async-mode in each
> > >>> ProtocolInvoker.
> > >>>>>> ProtocolInvoker could concentrate on async logic and we could
> > >> handle
> > >>>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain
> > >>> into
> > >>>> a
> > >>>>>> SyncInvocationChain.
> > >>>>>>
> > >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> > >>> param/returnType.
> > >>>>>> really a nice feature.
> > >>>>>>
> > >>>>>> Please let me known your opinion on my points. I'm also glad to
> > >> just
> > >>>> give
> > >>>>>> it a try and raise a pr.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > >>>>>>
> > >>>>>>> Hi folks,
> > >>>>>>>
> > >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> > >>>>> hopefully
> > >>>>>> we
> > >>>>>>> can start the vote in the early of the next week. But the main
> > >>>> purpose
> > >>>>> of
> > >>>>>>> this email is not a release announcement. Instead, since we now
> > >>> have
> > >>>>>>> bandwidth, let's consider and discuss what we should focus out
> > >> from
> > >>>>> many
> > >>>>>>> stuff we want to do. For example, we may focus more on issue and
> > >>> pull
> > >>>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
> > >>>> after
> > >>>>> we
> > >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> > >> plan
> > >>>>> which
> > >>>>>>> I'm now caring most, that is, how we define what version 3.0 is?
> > >>> and
> > >>>>> when
> > >>>>>>> can we get start on it? In my opinion, we need to start it right
> > >>> from
> > >>>>>> this
> > >>>>>>> moment.
> > >>>>>>>
> > >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> > >> the
> > >>>> same
> > >>>>>>> topic [1] in July this year. I summarize his points here if you
> > >> are
> > >>>> too
> > >>>>>>> impatient to read through the contents of his email :p:
> > >>>>>>>
> > >>>>>>> 1. Need to enhance the current extension mechanism
> > >>>>>>> 2. Need to enhance the code base for better maintenance
> > >>>>>>> 3. Need to support async
> > >>>>>>> 4. Need to decouple registry server and config server
> > >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> > >>>> features
> > >>>>>> in
> > >>>>>>> Dubbo's core
> > >>>>>>>
> > >>>>>>> I agree with most of his points in this good proposal.
> > >>>>>>>
> > >>>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0,
> > >>> or
> > >>>> in
> > >>>>>> the
> > >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> > >>>> opinion,
> > >>>>> I
> > >>>>>>> think we need to answer the following questions in this major
> > >>>> release:
> > >>>>>>>
> > >>>>>>> - Today the boundary between messaging and remoting call gets
> > >> blur.
> > >>>> We
> > >>>>>> may
> > >>>>>>> need to consider to support streaming at the protocol level.
> > >>>>>>> - Reative programming and its fundamental FP start to get
> > >> adopted.
> > >>> We
> > >>>>>>> should consider to support it.
> > >>>>>>> - Dubbo should be redesigned to support async better, and treats
> > >>>> async
> > >>>>> as
> > >>>>>>> the first class citizen. We do support async feature in 2.7.0
> > >>> release
> > >>>>> but
> > >>>>>>> it is not so perfect.
> > >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> > >>> seamlessly
> > >>>>> with
> > >>>>>>> micro-services becomes a question mark. We need to look into the
> > >>>>> inter-op
> > >>>>>>> between Dubbo and micro-services's registry server/config server.
> > >>> The
> > >>>>>>> support on separating registry server and config server in 2.7.0
> > >>>>> release
> > >>>>>> is
> > >>>>>>> a good start, but there are still lots of further works remaining
> > >>>> with
> > >>>>> no
> > >>>>>>> doubt.
> > >>>>>>> - Once we conquer seamless micro-services support, we still need
> > >> to
> > >>>>> take
> > >>>>>>> one step further to think about K8S integration. After all, K8S
> > >> and
> > >>>>>> service
> > >>>>>>> mesh built above it are now considered the best way for
> > >>>> micro-services
> > >>>>>>> deployment.
> > >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> > >>>> minimal
> > >>>>>>> feature set we should define for Dubbo framework. The reason
> > >> behind
> > >>>>> this
> > >>>>>>> is, it is very helpful for developing more language supports from
> > >>> the
> > >>>>>>> community. This also means, we need to modularize Dubbo further,
> > >> to
> > >>>>> make
> > >>>>>> it
> > >>>>>>> a reference implementation for other languages.
> > >>>>>>>
> > >>>>>>> In short, I suggest we need to focus on streaming protocol,
> > >> Rx/FP,
> > >>>>> native
> > >>>>>>> async, micro-services support, refactor/modularize areas. Of
> > >>> course,
> > >>>>>> there
> > >>>>>>> are more I don't mention in this email, for examples: how we make
> > >>>> Dubbo
> > >>>>>>> more resilient? how we support HTTP/2? and more.
> > >>>>>>>
> > >>>>>>> Pls. let me know your opinion on what I and Liujie proposed, and
> > >>>> share
> > >>>>>> your
> > >>>>>>> thought on what kind of features really matter to you.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> -Ian.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > >>>>>>> dev@dubbo.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
>

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

[Ian Luo <ia...@gmail.com>]

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_liu@163.com <zh...@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 <by...@gmail.com>
> *Date:* 2019-01-22 22:55
> *To:* dev <de...@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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：
>
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> >
> > Agree!  We should start as soon as possible, from 2.7.x.
> >
> > Jun
> >
> > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com>
> wrote:
> > >
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> > >
> > > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> > >
> > >> Yuhao, good idea.
> > >>
> > >> BTW, do you have any thought on what Dubbo 3.0 should be?
> > >>
> > >> Thanks,
> > >> -Ian.
> > >>
> > >>
> > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> > >>
> > >>> Once we have decided what to do in the next.
> > >>> Should we have a website page to publish it? e.g. [1]
> > >>>
> > >>> [1]. https://phoenix.apache.org/roadmap.html
> > >>>
> > >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> > >>>
> > >>>> Hi Ian Luo,
> > >>>>
> > >>>> OK, i'd start to work on it soon.
> > >>>>
> > >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> > >>>>
> > >>>>> Hi Yuneng,
> > >>>>>
> > >>>>> Sounds interesting. I am especially interested in reactive
> > >> programming
> > >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Ian.
> > >>>>>
> > >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> > >>> wrote:
> > >>>>>
> > >>>>>> Hi folks,
> > >>>>>>
> > >>>>>> I agreed with Ian Luo on the improvement list. I also got some
> idea
> > >>> in
> > >>>> my
> > >>>>>> mind.  I'd just share with you two points below in detail which
> i'm
> > >>>> most
> > >>>>>> interested in right now.
> > >>>>>>
> > >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> > >> mode,
> > >>>> to
> > >>>>> an
> > >>>>>> abstraction works in async mode. then we can construct
> > >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> > >>>> abstraction
> > >>>>>> works in async mode would simplify the sync/async logic. We  no
> > >>> longer
> > >>>>> need
> > >>>>>> to repeat the logic about sync-mode/async-mode in each
> > >>> ProtocolInvoker.
> > >>>>>> ProtocolInvoker could concentrate on async logic and we could
> > >> handle
> > >>>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain
> > >>> into
> > >>>> a
> > >>>>>> SyncInvocationChain.
> > >>>>>>
> > >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> > >>> param/returnType.
> > >>>>>> really a nice feature.
> > >>>>>>
> > >>>>>> Please let me known your opinion on my points. I'm also glad to
> > >> just
> > >>>> give
> > >>>>>> it a try and raise a pr.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > >>>>>>
> > >>>>>>> Hi folks,
> > >>>>>>>
> > >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> > >>>>> hopefully
> > >>>>>> we
> > >>>>>>> can start the vote in the early of the next week. But the main
> > >>>> purpose
> > >>>>> of
> > >>>>>>> this email is not a release announcement. Instead, since we now
> > >>> have
> > >>>>>>> bandwidth, let's consider and discuss what we should focus out
> > >> from
> > >>>>> many
> > >>>>>>> stuff we want to do. For example, we may focus more on issue and
> > >>> pull
> > >>>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
> > >>>> after
> > >>>>> we
> > >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> > >> plan
> > >>>>> which
> > >>>>>>> I'm now caring most, that is, how we define what version 3.0 is?
> > >>> and
> > >>>>> when
> > >>>>>>> can we get start on it? In my opinion, we need to start it right
> > >>> from
> > >>>>>> this
> > >>>>>>> moment.
> > >>>>>>>
> > >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> > >> the
> > >>>> same
> > >>>>>>> topic [1] in July this year. I summarize his points here if you
> > >> are
> > >>>> too
> > >>>>>>> impatient to read through the contents of his email :p:
> > >>>>>>>
> > >>>>>>> 1. Need to enhance the current extension mechanism
> > >>>>>>> 2. Need to enhance the code base for better maintenance
> > >>>>>>> 3. Need to support async
> > >>>>>>> 4. Need to decouple registry server and config server
> > >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> > >>>> features
> > >>>>>> in
> > >>>>>>> Dubbo's core
> > >>>>>>>
> > >>>>>>> I agree with most of his points in this good proposal.
> > >>>>>>>
> > >>>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0,
> > >>> or
> > >>>> in
> > >>>>>> the
> > >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> > >>>> opinion,
> > >>>>> I
> > >>>>>>> think we need to answer the following questions in this major
> > >>>> release:
> > >>>>>>>
> > >>>>>>> - Today the boundary between messaging and remoting call gets
> > >> blur.
> > >>>> We
> > >>>>>> may
> > >>>>>>> need to consider to support streaming at the protocol level.
> > >>>>>>> - Reative programming and its fundamental FP start to get
> > >> adopted.
> > >>> We
> > >>>>>>> should consider to support it.
> > >>>>>>> - Dubbo should be redesigned to support async better, and treats
> > >>>> async
> > >>>>> as
> > >>>>>>> the first class citizen. We do support async feature in 2.7.0
> > >>> release
> > >>>>> but
> > >>>>>>> it is not so perfect.
> > >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> > >>> seamlessly
> > >>>>> with
> > >>>>>>> micro-services becomes a question mark. We need to look into the
> > >>>>> inter-op
> > >>>>>>> between Dubbo and micro-services's registry server/config server.
> > >>> The
> > >>>>>>> support on separating registry server and config server in 2.7.0
> > >>>>> release
> > >>>>>> is
> > >>>>>>> a good start, but there are still lots of further works remaining
> > >>>> with
> > >>>>> no
> > >>>>>>> doubt.
> > >>>>>>> - Once we conquer seamless micro-services support, we still need
> > >> to
> > >>>>> take
> > >>>>>>> one step further to think about K8S integration. After all, K8S
> > >> and
> > >>>>>> service
> > >>>>>>> mesh built above it are now considered the best way for
> > >>>> micro-services
> > >>>>>>> deployment.
> > >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> > >>>> minimal
> > >>>>>>> feature set we should define for Dubbo framework. The reason
> > >> behind
> > >>>>> this
> > >>>>>>> is, it is very helpful for developing more language supports from
> > >>> the
> > >>>>>>> community. This also means, we need to modularize Dubbo further,
> > >> to
> > >>>>> make
> > >>>>>> it
> > >>>>>>> a reference implementation for other languages.
> > >>>>>>>
> > >>>>>>> In short, I suggest we need to focus on streaming protocol,
> > >> Rx/FP,
> > >>>>> native
> > >>>>>>> async, micro-services support, refactor/modularize areas. Of
> > >>> course,
> > >>>>>> there
> > >>>>>>> are more I don't mention in this email, for examples: how we make
> > >>>> Dubbo
> > >>>>>>> more resilient? how we support HTTP/2? and more.
> > >>>>>>>
> > >>>>>>> Pls. let me know your opinion on what I and Liujie proposed, and
> > >>>> share
> > >>>>>> your
> > >>>>>>> thought on what kind of features really matter to you.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> -Ian.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > >>>>>>> dev@dubbo.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
>

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

[jun liu <ke...@gmail.com>]

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_liu@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 <ma...@gmail.com>
> Date: 2019-01-22 22:55
> To: dev <ma...@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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：
>  
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> >
> > Agree!  We should start as soon as possible, from 2.7.x.
> >
> > Jun
> >
> > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com> wrote:
> > >
> > > I think the online integration test and performance test environment
> > should
> > > be set up for the new features.
> > >
> > > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> > >
> > >> Yuhao, good idea.
> > >>
> > >> BTW, do you have any thought on what Dubbo 3.0 should be?
> > >>
> > >> Thanks,
> > >> -Ian.
> > >>
> > >>
> > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> > >>
> > >>> Once we have decided what to do in the next.
> > >>> Should we have a website page to publish it? e.g. [1]
> > >>>
> > >>> [1]. https://phoenix.apache.org/roadmap.html
> > >>>
> > >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> > >>>
> > >>>> Hi Ian Luo,
> > >>>>
> > >>>> OK, i'd start to work on it soon.
> > >>>>
> > >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> > >>>>
> > >>>>> Hi Yuneng,
> > >>>>>
> > >>>>> Sounds interesting. I am especially interested in reactive
> > >> programming
> > >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Ian.
> > >>>>>
> > >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> > >>> wrote:
> > >>>>>
> > >>>>>> Hi folks,
> > >>>>>>
> > >>>>>> I agreed with Ian Luo on the improvement list. I also got some idea
> > >>> in
> > >>>> my
> > >>>>>> mind.  I'd just share with you two points below in detail which i'm
> > >>>> most
> > >>>>>> interested in right now.
> > >>>>>>
> > >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> > >> mode,
> > >>>> to
> > >>>>> an
> > >>>>>> abstraction works in async mode. then we can construct
> > >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> > >>>> abstraction
> > >>>>>> works in async mode would simplify the sync/async logic. We  no
> > >>> longer
> > >>>>> need
> > >>>>>> to repeat the logic about sync-mode/async-mode in each
> > >>> ProtocolInvoker.
> > >>>>>> ProtocolInvoker could concentrate on async logic and we could
> > >> handle
> > >>>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain
> > >>> into
> > >>>> a
> > >>>>>> SyncInvocationChain.
> > >>>>>>
> > >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> > >>> param/returnType.
> > >>>>>> really a nice feature.
> > >>>>>>
> > >>>>>> Please let me known your opinion on my points. I'm also glad to
> > >> just
> > >>>> give
> > >>>>>> it a try and raise a pr.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > >>>>>>
> > >>>>>>> Hi folks,
> > >>>>>>>
> > >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> > >>>>> hopefully
> > >>>>>> we
> > >>>>>>> can start the vote in the early of the next week. But the main
> > >>>> purpose
> > >>>>> of
> > >>>>>>> this email is not a release announcement. Instead, since we now
> > >>> have
> > >>>>>>> bandwidth, let's consider and discuss what we should focus out
> > >> from
> > >>>>> many
> > >>>>>>> stuff we want to do. For example, we may focus more on issue and
> > >>> pull
> > >>>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
> > >>>> after
> > >>>>> we
> > >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> > >> plan
> > >>>>> which
> > >>>>>>> I'm now caring most, that is, how we define what version 3.0 is?
> > >>> and
> > >>>>> when
> > >>>>>>> can we get start on it? In my opinion, we need to start it right
> > >>> from
> > >>>>>> this
> > >>>>>>> moment.
> > >>>>>>>
> > >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> > >> the
> > >>>> same
> > >>>>>>> topic [1] in July this year. I summarize his points here if you
> > >> are
> > >>>> too
> > >>>>>>> impatient to read through the contents of his email :p:
> > >>>>>>>
> > >>>>>>> 1. Need to enhance the current extension mechanism
> > >>>>>>> 2. Need to enhance the code base for better maintenance
> > >>>>>>> 3. Need to support async
> > >>>>>>> 4. Need to decouple registry server and config server
> > >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> > >>>> features
> > >>>>>> in
> > >>>>>>> Dubbo's core
> > >>>>>>>
> > >>>>>>> I agree with most of his points in this good proposal.
> > >>>>>>>
> > >>>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0,
> > >>> or
> > >>>> in
> > >>>>>> the
> > >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> > >>>> opinion,
> > >>>>> I
> > >>>>>>> think we need to answer the following questions in this major
> > >>>> release:
> > >>>>>>>
> > >>>>>>> - Today the boundary between messaging and remoting call gets
> > >> blur.
> > >>>> We
> > >>>>>> may
> > >>>>>>> need to consider to support streaming at the protocol level.
> > >>>>>>> - Reative programming and its fundamental FP start to get
> > >> adopted.
> > >>> We
> > >>>>>>> should consider to support it.
> > >>>>>>> - Dubbo should be redesigned to support async better, and treats
> > >>>> async
> > >>>>> as
> > >>>>>>> the first class citizen. We do support async feature in 2.7.0
> > >>> release
> > >>>>> but
> > >>>>>>> it is not so perfect.
> > >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> > >>> seamlessly
> > >>>>> with
> > >>>>>>> micro-services becomes a question mark. We need to look into the
> > >>>>> inter-op
> > >>>>>>> between Dubbo and micro-services's registry server/config server.
> > >>> The
> > >>>>>>> support on separating registry server and config server in 2.7.0
> > >>>>> release
> > >>>>>> is
> > >>>>>>> a good start, but there are still lots of further works remaining
> > >>>> with
> > >>>>> no
> > >>>>>>> doubt.
> > >>>>>>> - Once we conquer seamless micro-services support, we still need
> > >> to
> > >>>>> take
> > >>>>>>> one step further to think about K8S integration. After all, K8S
> > >> and
> > >>>>>> service
> > >>>>>>> mesh built above it are now considered the best way for
> > >>>> micro-services
> > >>>>>>> deployment.
> > >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> > >>>> minimal
> > >>>>>>> feature set we should define for Dubbo framework. The reason
> > >> behind
> > >>>>> this
> > >>>>>>> is, it is very helpful for developing more language supports from
> > >>> the
> > >>>>>>> community. This also means, we need to modularize Dubbo further,
> > >> to
> > >>>>> make
> > >>>>>> it
> > >>>>>>> a reference implementation for other languages.
> > >>>>>>>
> > >>>>>>> In short, I suggest we need to focus on streaming protocol,
> > >> Rx/FP,
> > >>>>> native
> > >>>>>>> async, micro-services support, refactor/modularize areas. Of
> > >>> course,
> > >>>>>> there
> > >>>>>>> are more I don't mention in this email, for examples: how we make
> > >>>> Dubbo
> > >>>>>>> more resilient? how we support HTTP/2? and more.
> > >>>>>>>
> > >>>>>>> Pls. let me know your opinion on what I and Liujie proposed, and
> > >>>> share
> > >>>>>> your
> > >>>>>>> thought on what kind of features really matter to you.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> -Ian.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > >>>>>>> dev@dubbo.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >

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

["zhi_guang_liu@163.com" <zh...@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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：
 
> > I think the online integration test and performance test environment
> should
> > be set up for the new features.
>
> Agree!  We should start as soon as possible, from 2.7.x.
>
> Jun
>
> > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com> wrote:
> >
> > I think the online integration test and performance test environment
> should
> > be set up for the new features.
> >
> > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> >
> >> Yuhao, good idea.
> >>
> >> BTW, do you have any thought on what Dubbo 3.0 should be?
> >>
> >> Thanks,
> >> -Ian.
> >>
> >>
> >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> >>
> >>> Once we have decided what to do in the next.
> >>> Should we have a website page to publish it? e.g. [1]
> >>>
> >>> [1]. https://phoenix.apache.org/roadmap.html
> >>>
> >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> >>>
> >>>> Hi Ian Luo,
> >>>>
> >>>> OK, i'd start to work on it soon.
> >>>>
> >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> >>>>
> >>>>> Hi Yuneng,
> >>>>>
> >>>>> Sounds interesting. I am especially interested in reactive
> >> programming
> >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> >>>>>
> >>>>> Thanks,
> >>>>> -Ian.
> >>>>>
> >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>>> Hi folks,
> >>>>>>
> >>>>>> I agreed with Ian Luo on the improvement list. I also got some idea
> >>> in
> >>>> my
> >>>>>> mind.  I'd just share with you two points below in detail which i'm
> >>>> most
> >>>>>> interested in right now.
> >>>>>>
> >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> >> mode,
> >>>> to
> >>>>> an
> >>>>>> abstraction works in async mode. then we can construct
> >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> >>>> abstraction
> >>>>>> works in async mode would simplify the sync/async logic. We  no
> >>> longer
> >>>>> need
> >>>>>> to repeat the logic about sync-mode/async-mode in each
> >>> ProtocolInvoker.
> >>>>>> ProtocolInvoker could concentrate on async logic and we could
> >> handle
> >>>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain
> >>> into
> >>>> a
> >>>>>> SyncInvocationChain.
> >>>>>>
> >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> >>> param/returnType.
> >>>>>> really a nice feature.
> >>>>>>
> >>>>>> Please let me known your opinion on my points. I'm also glad to
> >> just
> >>>> give
> >>>>>> it a try and raise a pr.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> >>>>>>
> >>>>>>> Hi folks,
> >>>>>>>
> >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> >>>>> hopefully
> >>>>>> we
> >>>>>>> can start the vote in the early of the next week. But the main
> >>>> purpose
> >>>>> of
> >>>>>>> this email is not a release announcement. Instead, since we now
> >>> have
> >>>>>>> bandwidth, let's consider and discuss what we should focus out
> >> from
> >>>>> many
> >>>>>>> stuff we want to do. For example, we may focus more on issue and
> >>> pull
> >>>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
> >>>> after
> >>>>> we
> >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> >> plan
> >>>>> which
> >>>>>>> I'm now caring most, that is, how we define what version 3.0 is?
> >>> and
> >>>>> when
> >>>>>>> can we get start on it? In my opinion, we need to start it right
> >>> from
> >>>>>> this
> >>>>>>> moment.
> >>>>>>>
> >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> >> the
> >>>> same
> >>>>>>> topic [1] in July this year. I summarize his points here if you
> >> are
> >>>> too
> >>>>>>> impatient to read through the contents of his email :p:
> >>>>>>>
> >>>>>>> 1. Need to enhance the current extension mechanism
> >>>>>>> 2. Need to enhance the code base for better maintenance
> >>>>>>> 3. Need to support async
> >>>>>>> 4. Need to decouple registry server and config server
> >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> >>>> features
> >>>>>> in
> >>>>>>> Dubbo's core
> >>>>>>>
> >>>>>>> I agree with most of his points in this good proposal.
> >>>>>>>
> >>>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0,
> >>> or
> >>>> in
> >>>>>> the
> >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> >>>> opinion,
> >>>>> I
> >>>>>>> think we need to answer the following questions in this major
> >>>> release:
> >>>>>>>
> >>>>>>> - Today the boundary between messaging and remoting call gets
> >> blur.
> >>>> We
> >>>>>> may
> >>>>>>> need to consider to support streaming at the protocol level.
> >>>>>>> - Reative programming and its fundamental FP start to get
> >> adopted.
> >>> We
> >>>>>>> should consider to support it.
> >>>>>>> - Dubbo should be redesigned to support async better, and treats
> >>>> async
> >>>>> as
> >>>>>>> the first class citizen. We do support async feature in 2.7.0
> >>> release
> >>>>> but
> >>>>>>> it is not so perfect.
> >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> >>> seamlessly
> >>>>> with
> >>>>>>> micro-services becomes a question mark. We need to look into the
> >>>>> inter-op
> >>>>>>> between Dubbo and micro-services's registry server/config server.
> >>> The
> >>>>>>> support on separating registry server and config server in 2.7.0
> >>>>> release
> >>>>>> is
> >>>>>>> a good start, but there are still lots of further works remaining
> >>>> with
> >>>>> no
> >>>>>>> doubt.
> >>>>>>> - Once we conquer seamless micro-services support, we still need
> >> to
> >>>>> take
> >>>>>>> one step further to think about K8S integration. After all, K8S
> >> and
> >>>>>> service
> >>>>>>> mesh built above it are now considered the best way for
> >>>> micro-services
> >>>>>>> deployment.
> >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> >>>> minimal
> >>>>>>> feature set we should define for Dubbo framework. The reason
> >> behind
> >>>>> this
> >>>>>>> is, it is very helpful for developing more language supports from
> >>> the
> >>>>>>> community. This also means, we need to modularize Dubbo further,
> >> to
> >>>>> make
> >>>>>> it
> >>>>>>> a reference implementation for other languages.
> >>>>>>>
> >>>>>>> In short, I suggest we need to focus on streaming protocol,
> >> Rx/FP,
> >>>>> native
> >>>>>>> async, micro-services support, refactor/modularize areas. Of
> >>> course,
> >>>>>> there
> >>>>>>> are more I don't mention in this email, for examples: how we make
> >>>> Dubbo
> >>>>>>> more resilient? how we support HTTP/2? and more.
> >>>>>>>
> >>>>>>> Pls. let me know your opinion on what I and Liujie proposed, and
> >>>> share
> >>>>>> your
> >>>>>>> thought on what kind of features really matter to you.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> -Ian.
> >>>>>>>
> >>>>>>>
> >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> >>>>>>> dev@dubbo.apache.org
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

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

[Yuhao Bi <by...@gmail.com>]

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 <ke...@gmail.com> 于2019年1月22日周二 下午5:50写道：

> > I think the online integration test and performance test environment
> should
> > be set up for the new features.
>
> Agree!  We should start as soon as possible, from 2.7.x.
>
> Jun
>
> > On Jan 22, 2019, at 5:43 PM, Xin Wang <xi...@gmail.com> wrote:
> >
> > I think the online integration test and performance test environment
> should
> > be set up for the new features.
> >
> > Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> >
> >> Yuhao, good idea.
> >>
> >> BTW, do you have any thought on what Dubbo 3.0 should be?
> >>
> >> Thanks,
> >> -Ian.
> >>
> >>
> >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
> >>
> >>> Once we have decided what to do in the next.
> >>> Should we have a website page to publish it? e.g. [1]
> >>>
> >>> [1]. https://phoenix.apache.org/roadmap.html
> >>>
> >>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> >>>
> >>>> Hi Ian Luo,
> >>>>
> >>>> OK, i'd start to work on it soon.
> >>>>
> >>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> >>>>
> >>>>> Hi Yuneng,
> >>>>>
> >>>>> Sounds interesting. I am especially interested in reactive
> >> programming
> >>>>> support. Pls. go ahead to try implement it on 3.x branch.
> >>>>>
> >>>>> Thanks,
> >>>>> -Ian.
> >>>>>
> >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>>> Hi folks,
> >>>>>>
> >>>>>> I agreed with Ian Luo on the improvement list. I also got some idea
> >>> in
> >>>> my
> >>>>>> mind.  I'd just share with you two points below in detail which i'm
> >>>> most
> >>>>>> interested in right now.
> >>>>>>
> >>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
> >> mode,
> >>>> to
> >>>>> an
> >>>>>> abstraction works in async mode. then we can construct
> >>>>>> InvocationChain/FilterChain that works in async mode.  A core
> >>>> abstraction
> >>>>>> works in async mode would simplify the sync/async logic. We  no
> >>> longer
> >>>>> need
> >>>>>> to repeat the logic about sync-mode/async-mode in each
> >>> ProtocolInvoker.
> >>>>>> ProtocolInvoker could concentrate on async logic and we could
> >> handle
> >>>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain
> >>> into
> >>>> a
> >>>>>> SyncInvocationChain.
> >>>>>>
> >>>>>> 2. Support using stream-value (Fowable, Flux...)  as
> >>> param/returnType.
> >>>>>> really a nice feature.
> >>>>>>
> >>>>>> Please let me known your opinion on my points. I'm also glad to
> >> just
> >>>> give
> >>>>>> it a try and raise a pr.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> >>>>>>
> >>>>>>> Hi folks,
> >>>>>>>
> >>>>>>> Finally we managed to ramp down version 2.7.0 development, and
> >>>>> hopefully
> >>>>>> we
> >>>>>>> can start the vote in the early of the next week. But the main
> >>>> purpose
> >>>>> of
> >>>>>>> this email is not a release announcement. Instead, since we now
> >>> have
> >>>>>>> bandwidth, let's consider and discuss what we should focus out
> >> from
> >>>>> many
> >>>>>>> stuff we want to do. For example, we may focus more on issue and
> >>> pull
> >>>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
> >>>> after
> >>>>> we
> >>>>>>> release 2.7.0. But today I'd like to bring up one longer term
> >> plan
> >>>>> which
> >>>>>>> I'm now caring most, that is, how we define what version 3.0 is?
> >>> and
> >>>>> when
> >>>>>>> can we get start on it? In my opinion, we need to start it right
> >>> from
> >>>>>> this
> >>>>>>> moment.
> >>>>>>>
> >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
> >> the
> >>>> same
> >>>>>>> topic [1] in July this year. I summarize his points here if you
> >> are
> >>>> too
> >>>>>>> impatient to read through the contents of his email :p:
> >>>>>>>
> >>>>>>> 1. Need to enhance the current extension mechanism
> >>>>>>> 2. Need to enhance the code base for better maintenance
> >>>>>>> 3. Need to support async
> >>>>>>> 4. Need to decouple registry server and config server
> >>>>>>> 5. Need to support Java8 and above so that we can use advanced
> >>>> features
> >>>>>> in
> >>>>>>> Dubbo's core
> >>>>>>>
> >>>>>>> I agree with most of his points in this good proposal.
> >>>>>>>
> >>>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0,
> >>> or
> >>>> in
> >>>>>> the
> >>>>>>> other word, how do the community expect from Dubbo 3.0. In my
> >>>> opinion,
> >>>>> I
> >>>>>>> think we need to answer the following questions in this major
> >>>> release:
> >>>>>>>
> >>>>>>> - Today the boundary between messaging and remoting call gets
> >> blur.
> >>>> We
> >>>>>> may
> >>>>>>> need to consider to support streaming at the protocol level.
> >>>>>>> - Reative programming and its fundamental FP start to get
> >> adopted.
> >>> We
> >>>>>>> should consider to support it.
> >>>>>>> - Dubbo should be redesigned to support async better, and treats
> >>>> async
> >>>>> as
> >>>>>>> the first class citizen. We do support async feature in 2.7.0
> >>> release
> >>>>> but
> >>>>>>> it is not so perfect.
> >>>>>>> - Micro-services has been widely adopted. How Dubbo works
> >>> seamlessly
> >>>>> with
> >>>>>>> micro-services becomes a question mark. We need to look into the
> >>>>> inter-op
> >>>>>>> between Dubbo and micro-services's registry server/config server.
> >>> The
> >>>>>>> support on separating registry server and config server in 2.7.0
> >>>>> release
> >>>>>> is
> >>>>>>> a good start, but there are still lots of further works remaining
> >>>> with
> >>>>> no
> >>>>>>> doubt.
> >>>>>>> - Once we conquer seamless micro-services support, we still need
> >> to
> >>>>> take
> >>>>>>> one step further to think about K8S integration. After all, K8S
> >> and
> >>>>>> service
> >>>>>>> mesh built above it are now considered the best way for
> >>>> micro-services
> >>>>>>> deployment.
> >>>>>>> - How we define mini-dubbo, or phrase in another way, what the
> >>>> minimal
> >>>>>>> feature set we should define for Dubbo framework. The reason
> >> behind
> >>>>> this
> >>>>>>> is, it is very helpful for developing more language supports from
> >>> the
> >>>>>>> community. This also means, we need to modularize Dubbo further,
> >> to
> >>>>> make
> >>>>>> it
> >>>>>>> a reference implementation for other languages.
> >>>>>>>
> >>>>>>> In short, I suggest we need to focus on streaming protocol,
> >> Rx/FP,
> >>>>> native
> >>>>>>> async, micro-services support, refactor/modularize areas. Of
> >>> course,
> >>>>>> there
> >>>>>>> are more I don't mention in this email, for examples: how we make
> >>>> Dubbo
> >>>>>>> more resilient? how we support HTTP/2? and more.
> >>>>>>>
> >>>>>>> Pls. let me know your opinion on what I and Liujie proposed, and
> >>>> share
> >>>>>> your
> >>>>>>> thought on what kind of features really matter to you.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> -Ian.
> >>>>>>>
> >>>>>>>
> >>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> >>>>>>> dev@dubbo.apache.org
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

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

[jun liu <ke...@gmail.com>]

> 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 <xi...@gmail.com> wrote:
> 
> I think the online integration test and performance test environment should
> be set up for the new features.
> 
> Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：
> 
>> Yuhao, good idea.
>> 
>> BTW, do you have any thought on what Dubbo 3.0 should be?
>> 
>> Thanks,
>> -Ian.
>> 
>> 
>> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
>> 
>>> Once we have decided what to do in the next.
>>> Should we have a website page to publish it? e.g. [1]
>>> 
>>> [1]. https://phoenix.apache.org/roadmap.html
>>> 
>>> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
>>> 
>>>> Hi Ian Luo,
>>>> 
>>>> OK, i'd start to work on it soon.
>>>> 
>>>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
>>>> 
>>>>> Hi Yuneng,
>>>>> 
>>>>> Sounds interesting. I am especially interested in reactive
>> programming
>>>>> support. Pls. go ahead to try implement it on 3.x branch.
>>>>> 
>>>>> Thanks,
>>>>> -Ian.
>>>>> 
>>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
>>> wrote:
>>>>> 
>>>>>> Hi folks,
>>>>>> 
>>>>>> I agreed with Ian Luo on the improvement list. I also got some idea
>>> in
>>>> my
>>>>>> mind.  I'd just share with you two points below in detail which i'm
>>>> most
>>>>>> interested in right now.
>>>>>> 
>>>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync
>> mode,
>>>> to
>>>>> an
>>>>>> abstraction works in async mode. then we can construct
>>>>>> InvocationChain/FilterChain that works in async mode.  A core
>>>> abstraction
>>>>>> works in async mode would simplify the sync/async logic. We  no
>>> longer
>>>>> need
>>>>>> to repeat the logic about sync-mode/async-mode in each
>>> ProtocolInvoker.
>>>>>> ProtocolInvoker could concentrate on async logic and we could
>> handle
>>>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain
>>> into
>>>> a
>>>>>> SyncInvocationChain.
>>>>>> 
>>>>>> 2. Support using stream-value (Fowable, Flux...)  as
>>> param/returnType.
>>>>>> really a nice feature.
>>>>>> 
>>>>>> Please let me known your opinion on my points. I'm also glad to
>> just
>>>> give
>>>>>> it a try and raise a pr.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
>>>>>> 
>>>>>>> Hi folks,
>>>>>>> 
>>>>>>> Finally we managed to ramp down version 2.7.0 development, and
>>>>> hopefully
>>>>>> we
>>>>>>> can start the vote in the early of the next week. But the main
>>>> purpose
>>>>> of
>>>>>>> this email is not a release announcement. Instead, since we now
>>> have
>>>>>>> bandwidth, let's consider and discuss what we should focus out
>> from
>>>>> many
>>>>>>> stuff we want to do. For example, we may focus more on issue and
>>> pull
>>>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
>>>> after
>>>>> we
>>>>>>> release 2.7.0. But today I'd like to bring up one longer term
>> plan
>>>>> which
>>>>>>> I'm now caring most, that is, how we define what version 3.0 is?
>>> and
>>>>> when
>>>>>>> can we get start on it? In my opinion, we need to start it right
>>> from
>>>>>> this
>>>>>>> moment.
>>>>>>> 
>>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on
>> the
>>>> same
>>>>>>> topic [1] in July this year. I summarize his points here if you
>> are
>>>> too
>>>>>>> impatient to read through the contents of his email :p:
>>>>>>> 
>>>>>>> 1. Need to enhance the current extension mechanism
>>>>>>> 2. Need to enhance the code base for better maintenance
>>>>>>> 3. Need to support async
>>>>>>> 4. Need to decouple registry server and config server
>>>>>>> 5. Need to support Java8 and above so that we can use advanced
>>>> features
>>>>>> in
>>>>>>> Dubbo's core
>>>>>>> 
>>>>>>> I agree with most of his points in this good proposal.
>>>>>>> 
>>>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0,
>>> or
>>>> in
>>>>>> the
>>>>>>> other word, how do the community expect from Dubbo 3.0. In my
>>>> opinion,
>>>>> I
>>>>>>> think we need to answer the following questions in this major
>>>> release:
>>>>>>> 
>>>>>>> - Today the boundary between messaging and remoting call gets
>> blur.
>>>> We
>>>>>> may
>>>>>>> need to consider to support streaming at the protocol level.
>>>>>>> - Reative programming and its fundamental FP start to get
>> adopted.
>>> We
>>>>>>> should consider to support it.
>>>>>>> - Dubbo should be redesigned to support async better, and treats
>>>> async
>>>>> as
>>>>>>> the first class citizen. We do support async feature in 2.7.0
>>> release
>>>>> but
>>>>>>> it is not so perfect.
>>>>>>> - Micro-services has been widely adopted. How Dubbo works
>>> seamlessly
>>>>> with
>>>>>>> micro-services becomes a question mark. We need to look into the
>>>>> inter-op
>>>>>>> between Dubbo and micro-services's registry server/config server.
>>> The
>>>>>>> support on separating registry server and config server in 2.7.0
>>>>> release
>>>>>> is
>>>>>>> a good start, but there are still lots of further works remaining
>>>> with
>>>>> no
>>>>>>> doubt.
>>>>>>> - Once we conquer seamless micro-services support, we still need
>> to
>>>>> take
>>>>>>> one step further to think about K8S integration. After all, K8S
>> and
>>>>>> service
>>>>>>> mesh built above it are now considered the best way for
>>>> micro-services
>>>>>>> deployment.
>>>>>>> - How we define mini-dubbo, or phrase in another way, what the
>>>> minimal
>>>>>>> feature set we should define for Dubbo framework. The reason
>> behind
>>>>> this
>>>>>>> is, it is very helpful for developing more language supports from
>>> the
>>>>>>> community. This also means, we need to modularize Dubbo further,
>> to
>>>>> make
>>>>>> it
>>>>>>> a reference implementation for other languages.
>>>>>>> 
>>>>>>> In short, I suggest we need to focus on streaming protocol,
>> Rx/FP,
>>>>> native
>>>>>>> async, micro-services support, refactor/modularize areas. Of
>>> course,
>>>>>> there
>>>>>>> are more I don't mention in this email, for examples: how we make
>>>> Dubbo
>>>>>>> more resilient? how we support HTTP/2? and more.
>>>>>>> 
>>>>>>> Pls. let me know your opinion on what I and Liujie proposed, and
>>>> share
>>>>>> your
>>>>>>> thought on what kind of features really matter to you.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> -Ian.
>>>>>>> 
>>>>>>> 
>>>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
>>>>>>> dev@dubbo.apache.org
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

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

[Xin Wang <xi...@gmail.com>]

I think the online integration test and performance test environment should
be set up for the new features.

Ian Luo <ia...@gmail.com> 于2019年1月22日周二 下午3:04写道：

> Yuhao, good idea.
>
> BTW, do you have any thought on what Dubbo 3.0 should be?
>
> Thanks,
> -Ian.
>
>
> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <by...@gmail.com> wrote:
>
> > Once we have decided what to do in the next.
> > Should we have a website page to publish it? e.g. [1]
> >
> > [1]. https://phoenix.apache.org/roadmap.html
> >
> > yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> >
> > > Hi Ian Luo,
> > >
> > > OK, i'd start to work on it soon.
> > >
> > > Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> > >
> > > > Hi Yuneng,
> > > >
> > > > Sounds interesting. I am especially interested in reactive
> programming
> > > > support. Pls. go ahead to try implement it on 3.x branch.
> > > >
> > > > Thanks,
> > > > -Ian.
> > > >
> > > > On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> > wrote:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > I agreed with Ian Luo on the improvement list. I also got some idea
> > in
> > > my
> > > > > mind.  I'd just share with you two points below in detail which i'm
> > > most
> > > > > interested in right now.
> > > > >
> > > > > 1. Upgrade  the core abstraction "Invoker", which works in sync
> mode,
> > > to
> > > > an
> > > > > abstraction works in async mode. then we can construct
> > > > > InvocationChain/FilterChain that works in async mode.  A core
> > > abstraction
> > > > > works in async mode would simplify the sync/async logic. We  no
> > longer
> > > > need
> > > > > to repeat the logic about sync-mode/async-mode in each
> > ProtocolInvoker.
> > > > > ProtocolInvoker could concentrate on async logic and we could
> handle
> > > > > sync-mode invoke all in once by wrapping the AsyncInvocationChain
> > into
> > > a
> > > > > SyncInvocationChain.
> > > > >
> > > > > 2. Support using stream-value (Fowable, Flux...)  as
> > param/returnType.
> > > > > really a nice feature.
> > > > >
> > > > > Please let me known your opinion on my points. I'm also glad to
> just
> > > give
> > > > > it a try and raise a pr.
> > > > >
> > > > >
> > > > >
> > > > > Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > > > >
> > > > > > Hi folks,
> > > > > >
> > > > > > Finally we managed to ramp down version 2.7.0 development, and
> > > > hopefully
> > > > > we
> > > > > > can start the vote in the early of the next week. But the main
> > > purpose
> > > > of
> > > > > > this email is not a release announcement. Instead, since we now
> > have
> > > > > > bandwidth, let's consider and discuss what we should focus out
> from
> > > > many
> > > > > > stuff we want to do. For example, we may focus more on issue and
> > pull
> > > > > > request on GitHub, or we may plan 2.7 minor releases immediately
> > > after
> > > > we
> > > > > > release 2.7.0. But today I'd like to bring up one longer term
> plan
> > > > which
> > > > > > I'm now caring most, that is, how we define what version 3.0 is?
> > and
> > > > when
> > > > > > can we get start on it? In my opinion, we need to start it right
> > from
> > > > > this
> > > > > > moment.
> > > > > >
> > > > > > I recalled Liujie Qin (@liujieqin) initialed the discussion on
> the
> > > same
> > > > > > topic [1] in July this year. I summarize his points here if you
> are
> > > too
> > > > > > impatient to read through the contents of his email :p:
> > > > > >
> > > > > > 1. Need to enhance the current extension mechanism
> > > > > > 2. Need to enhance the code base for better maintenance
> > > > > > 3. Need to support async
> > > > > > 4. Need to decouple registry server and config server
> > > > > > 5. Need to support Java8 and above so that we can use advanced
> > > features
> > > > > in
> > > > > > Dubbo's core
> > > > > >
> > > > > > I agree with most of his points in this good proposal.
> > > > > >
> > > > > > Here I'd like to initial a discussion on how we define Dubbo 3.0,
> > or
> > > in
> > > > > the
> > > > > > other word, how do the community expect from Dubbo 3.0. In my
> > > opinion,
> > > > I
> > > > > > think we need to answer the following questions in this major
> > > release:
> > > > > >
> > > > > > - Today the boundary between messaging and remoting call gets
> blur.
> > > We
> > > > > may
> > > > > > need to consider to support streaming at the protocol level.
> > > > > > - Reative programming and its fundamental FP start to get
> adopted.
> > We
> > > > > > should consider to support it.
> > > > > > - Dubbo should be redesigned to support async better, and treats
> > > async
> > > > as
> > > > > > the first class citizen. We do support async feature in 2.7.0
> > release
> > > > but
> > > > > > it is not so perfect.
> > > > > > - Micro-services has been widely adopted. How Dubbo works
> > seamlessly
> > > > with
> > > > > > micro-services becomes a question mark. We need to look into the
> > > > inter-op
> > > > > > between Dubbo and micro-services's registry server/config server.
> > The
> > > > > > support on separating registry server and config server in 2.7.0
> > > > release
> > > > > is
> > > > > > a good start, but there are still lots of further works remaining
> > > with
> > > > no
> > > > > > doubt.
> > > > > > - Once we conquer seamless micro-services support, we still need
> to
> > > > take
> > > > > > one step further to think about K8S integration. After all, K8S
> and
> > > > > service
> > > > > > mesh built above it are now considered the best way for
> > > micro-services
> > > > > > deployment.
> > > > > > - How we define mini-dubbo, or phrase in another way, what the
> > > minimal
> > > > > > feature set we should define for Dubbo framework. The reason
> behind
> > > > this
> > > > > > is, it is very helpful for developing more language supports from
> > the
> > > > > > community. This also means, we need to modularize Dubbo further,
> to
> > > > make
> > > > > it
> > > > > > a reference implementation for other languages.
> > > > > >
> > > > > > In short, I suggest we need to focus on streaming protocol,
> Rx/FP,
> > > > native
> > > > > > async, micro-services support, refactor/modularize areas. Of
> > course,
> > > > > there
> > > > > > are more I don't mention in this email, for examples: how we make
> > > Dubbo
> > > > > > more resilient? how we support HTTP/2? and more.
> > > > > >
> > > > > > Pls. let me know your opinion on what I and Liujie proposed, and
> > > share
> > > > > your
> > > > > > thought on what kind of features really matter to you.
> > > > > >
> > > > > > Thanks,
> > > > > > -Ian.
> > > > > >
> > > > > >
> > > > > > 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > > > > > dev@dubbo.apache.org
> > > > > >
> > > > >
> > > >
> > >
> >
>

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

[Ian Luo <ia...@gmail.com>]

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 <by...@gmail.com> wrote:

> Once we have decided what to do in the next.
> Should we have a website page to publish it? e.g. [1]
>
> [1]. https://phoenix.apache.org/roadmap.html
>
> yuneng xie <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
>
> > Hi Ian Luo,
> >
> > OK, i'd start to work on it soon.
> >
> > Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
> >
> > > Hi Yuneng,
> > >
> > > Sounds interesting. I am especially interested in reactive programming
> > > support. Pls. go ahead to try implement it on 3.x branch.
> > >
> > > Thanks,
> > > -Ian.
> > >
> > > On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com>
> wrote:
> > >
> > > > Hi folks,
> > > >
> > > > I agreed with Ian Luo on the improvement list. I also got some idea
> in
> > my
> > > > mind.  I'd just share with you two points below in detail which i'm
> > most
> > > > interested in right now.
> > > >
> > > > 1. Upgrade  the core abstraction "Invoker", which works in sync mode,
> > to
> > > an
> > > > abstraction works in async mode. then we can construct
> > > > InvocationChain/FilterChain that works in async mode.  A core
> > abstraction
> > > > works in async mode would simplify the sync/async logic. We  no
> longer
> > > need
> > > > to repeat the logic about sync-mode/async-mode in each
> ProtocolInvoker.
> > > > ProtocolInvoker could concentrate on async logic and we could handle
> > > > sync-mode invoke all in once by wrapping the AsyncInvocationChain
> into
> > a
> > > > SyncInvocationChain.
> > > >
> > > > 2. Support using stream-value (Fowable, Flux...)  as
> param/returnType.
> > > > really a nice feature.
> > > >
> > > > Please let me known your opinion on my points. I'm also glad to just
> > give
> > > > it a try and raise a pr.
> > > >
> > > >
> > > >
> > > > Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > > >
> > > > > Hi folks,
> > > > >
> > > > > Finally we managed to ramp down version 2.7.0 development, and
> > > hopefully
> > > > we
> > > > > can start the vote in the early of the next week. But the main
> > purpose
> > > of
> > > > > this email is not a release announcement. Instead, since we now
> have
> > > > > bandwidth, let's consider and discuss what we should focus out from
> > > many
> > > > > stuff we want to do. For example, we may focus more on issue and
> pull
> > > > > request on GitHub, or we may plan 2.7 minor releases immediately
> > after
> > > we
> > > > > release 2.7.0. But today I'd like to bring up one longer term plan
> > > which
> > > > > I'm now caring most, that is, how we define what version 3.0 is?
> and
> > > when
> > > > > can we get start on it? In my opinion, we need to start it right
> from
> > > > this
> > > > > moment.
> > > > >
> > > > > I recalled Liujie Qin (@liujieqin) initialed the discussion on the
> > same
> > > > > topic [1] in July this year. I summarize his points here if you are
> > too
> > > > > impatient to read through the contents of his email :p:
> > > > >
> > > > > 1. Need to enhance the current extension mechanism
> > > > > 2. Need to enhance the code base for better maintenance
> > > > > 3. Need to support async
> > > > > 4. Need to decouple registry server and config server
> > > > > 5. Need to support Java8 and above so that we can use advanced
> > features
> > > > in
> > > > > Dubbo's core
> > > > >
> > > > > I agree with most of his points in this good proposal.
> > > > >
> > > > > Here I'd like to initial a discussion on how we define Dubbo 3.0,
> or
> > in
> > > > the
> > > > > other word, how do the community expect from Dubbo 3.0. In my
> > opinion,
> > > I
> > > > > think we need to answer the following questions in this major
> > release:
> > > > >
> > > > > - Today the boundary between messaging and remoting call gets blur.
> > We
> > > > may
> > > > > need to consider to support streaming at the protocol level.
> > > > > - Reative programming and its fundamental FP start to get adopted.
> We
> > > > > should consider to support it.
> > > > > - Dubbo should be redesigned to support async better, and treats
> > async
> > > as
> > > > > the first class citizen. We do support async feature in 2.7.0
> release
> > > but
> > > > > it is not so perfect.
> > > > > - Micro-services has been widely adopted. How Dubbo works
> seamlessly
> > > with
> > > > > micro-services becomes a question mark. We need to look into the
> > > inter-op
> > > > > between Dubbo and micro-services's registry server/config server.
> The
> > > > > support on separating registry server and config server in 2.7.0
> > > release
> > > > is
> > > > > a good start, but there are still lots of further works remaining
> > with
> > > no
> > > > > doubt.
> > > > > - Once we conquer seamless micro-services support, we still need to
> > > take
> > > > > one step further to think about K8S integration. After all, K8S and
> > > > service
> > > > > mesh built above it are now considered the best way for
> > micro-services
> > > > > deployment.
> > > > > - How we define mini-dubbo, or phrase in another way, what the
> > minimal
> > > > > feature set we should define for Dubbo framework. The reason behind
> > > this
> > > > > is, it is very helpful for developing more language supports from
> the
> > > > > community. This also means, we need to modularize Dubbo further, to
> > > make
> > > > it
> > > > > a reference implementation for other languages.
> > > > >
> > > > > In short, I suggest we need to focus on streaming protocol, Rx/FP,
> > > native
> > > > > async, micro-services support, refactor/modularize areas. Of
> course,
> > > > there
> > > > > are more I don't mention in this email, for examples: how we make
> > Dubbo
> > > > > more resilient? how we support HTTP/2? and more.
> > > > >
> > > > > Pls. let me know your opinion on what I and Liujie proposed, and
> > share
> > > > your
> > > > > thought on what kind of features really matter to you.
> > > > >
> > > > > Thanks,
> > > > > -Ian.
> > > > >
> > > > >
> > > > > 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > > > > dev@dubbo.apache.org
> > > > >
> > > >
> > >
> >
>

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

[Yuhao Bi <by...@gmail.com>]

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 <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：

> Hi Ian Luo,
>
> OK, i'd start to work on it soon.
>
> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
>
> > Hi Yuneng,
> >
> > Sounds interesting. I am especially interested in reactive programming
> > support. Pls. go ahead to try implement it on 3.x branch.
> >
> > Thanks,
> > -Ian.
> >
> > On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com> wrote:
> >
> > > Hi folks,
> > >
> > > I agreed with Ian Luo on the improvement list. I also got some idea in
> my
> > > mind.  I'd just share with you two points below in detail which i'm
> most
> > > interested in right now.
> > >
> > > 1. Upgrade  the core abstraction "Invoker", which works in sync mode,
> to
> > an
> > > abstraction works in async mode. then we can construct
> > > InvocationChain/FilterChain that works in async mode.  A core
> abstraction
> > > works in async mode would simplify the sync/async logic. We  no longer
> > need
> > > to repeat the logic about sync-mode/async-mode in each ProtocolInvoker.
> > > ProtocolInvoker could concentrate on async logic and we could handle
> > > sync-mode invoke all in once by wrapping the AsyncInvocationChain into
> a
> > > SyncInvocationChain.
> > >
> > > 2. Support using stream-value (Fowable, Flux...)  as param/returnType.
> > > really a nice feature.
> > >
> > > Please let me known your opinion on my points. I'm also glad to just
> give
> > > it a try and raise a pr.
> > >
> > >
> > >
> > > Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> > >
> > > > Hi folks,
> > > >
> > > > Finally we managed to ramp down version 2.7.0 development, and
> > hopefully
> > > we
> > > > can start the vote in the early of the next week. But the main
> purpose
> > of
> > > > this email is not a release announcement. Instead, since we now have
> > > > bandwidth, let's consider and discuss what we should focus out from
> > many
> > > > stuff we want to do. For example, we may focus more on issue and pull
> > > > request on GitHub, or we may plan 2.7 minor releases immediately
> after
> > we
> > > > release 2.7.0. But today I'd like to bring up one longer term plan
> > which
> > > > I'm now caring most, that is, how we define what version 3.0 is? and
> > when
> > > > can we get start on it? In my opinion, we need to start it right from
> > > this
> > > > moment.
> > > >
> > > > I recalled Liujie Qin (@liujieqin) initialed the discussion on the
> same
> > > > topic [1] in July this year. I summarize his points here if you are
> too
> > > > impatient to read through the contents of his email :p:
> > > >
> > > > 1. Need to enhance the current extension mechanism
> > > > 2. Need to enhance the code base for better maintenance
> > > > 3. Need to support async
> > > > 4. Need to decouple registry server and config server
> > > > 5. Need to support Java8 and above so that we can use advanced
> features
> > > in
> > > > Dubbo's core
> > > >
> > > > I agree with most of his points in this good proposal.
> > > >
> > > > Here I'd like to initial a discussion on how we define Dubbo 3.0, or
> in
> > > the
> > > > other word, how do the community expect from Dubbo 3.0. In my
> opinion,
> > I
> > > > think we need to answer the following questions in this major
> release:
> > > >
> > > > - Today the boundary between messaging and remoting call gets blur.
> We
> > > may
> > > > need to consider to support streaming at the protocol level.
> > > > - Reative programming and its fundamental FP start to get adopted. We
> > > > should consider to support it.
> > > > - Dubbo should be redesigned to support async better, and treats
> async
> > as
> > > > the first class citizen. We do support async feature in 2.7.0 release
> > but
> > > > it is not so perfect.
> > > > - Micro-services has been widely adopted. How Dubbo works seamlessly
> > with
> > > > micro-services becomes a question mark. We need to look into the
> > inter-op
> > > > between Dubbo and micro-services's registry server/config server. The
> > > > support on separating registry server and config server in 2.7.0
> > release
> > > is
> > > > a good start, but there are still lots of further works remaining
> with
> > no
> > > > doubt.
> > > > - Once we conquer seamless micro-services support, we still need to
> > take
> > > > one step further to think about K8S integration. After all, K8S and
> > > service
> > > > mesh built above it are now considered the best way for
> micro-services
> > > > deployment.
> > > > - How we define mini-dubbo, or phrase in another way, what the
> minimal
> > > > feature set we should define for Dubbo framework. The reason behind
> > this
> > > > is, it is very helpful for developing more language supports from the
> > > > community. This also means, we need to modularize Dubbo further, to
> > make
> > > it
> > > > a reference implementation for other languages.
> > > >
> > > > In short, I suggest we need to focus on streaming protocol, Rx/FP,
> > native
> > > > async, micro-services support, refactor/modularize areas. Of course,
> > > there
> > > > are more I don't mention in this email, for examples: how we make
> Dubbo
> > > > more resilient? how we support HTTP/2? and more.
> > > >
> > > > Pls. let me know your opinion on what I and Liujie proposed, and
> share
> > > your
> > > > thought on what kind of features really matter to you.
> > > >
> > > > Thanks,
> > > > -Ian.
> > > >
> > > >
> > > > 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > > > dev@dubbo.apache.org
> > > >
> > >
> >
>

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

[jun liu <ke...@gmail.com>]

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 <xi...@gmail.com> 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 <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> 
>> Hi Ian Luo,
>> 
>> OK, i'd start to work on it soon.
>> 
>> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
>> 
>>> Hi Yuneng,
>>> 
>>> Sounds interesting. I am especially interested in reactive programming
>>> support. Pls. go ahead to try implement it on 3.x branch.
>>> 
>>> Thanks,
>>> -Ian.
>>> 
>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com> wrote:
>>> 
>>>> Hi folks,
>>>> 
>>>> I agreed with Ian Luo on the improvement list. I also got some idea in
>>> my
>>>> mind.  I'd just share with you two points below in detail which i'm most
>>>> interested in right now.
>>>> 
>>>> 1. Upgrade  the core abstraction "Invoker", which works in sync mode,
>>> to an
>>>> abstraction works in async mode. then we can construct
>>>> InvocationChain/FilterChain that works in async mode.  A core
>>> abstraction
>>>> works in async mode would simplify the sync/async logic. We  no longer
>>> need
>>>> to repeat the logic about sync-mode/async-mode in each ProtocolInvoker.
>>>> ProtocolInvoker could concentrate on async logic and we could handle
>>>> sync-mode invoke all in once by wrapping the AsyncInvocationChain into a
>>>> SyncInvocationChain.
>>>> 
>>>> 2. Support using stream-value (Fowable, Flux...)  as param/returnType.
>>>> really a nice feature.
>>>> 
>>>> Please let me known your opinion on my points. I'm also glad to just
>>> give
>>>> it a try and raise a pr.
>>>> 
>>>> 
>>>> 
>>>> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> Finally we managed to ramp down version 2.7.0 development, and
>>> hopefully
>>>> we
>>>>> can start the vote in the early of the next week. But the main
>>> purpose of
>>>>> this email is not a release announcement. Instead, since we now have
>>>>> bandwidth, let's consider and discuss what we should focus out from
>>> many
>>>>> stuff we want to do. For example, we may focus more on issue and pull
>>>>> request on GitHub, or we may plan 2.7 minor releases immediately
>>> after we
>>>>> release 2.7.0. But today I'd like to bring up one longer term plan
>>> which
>>>>> I'm now caring most, that is, how we define what version 3.0 is? and
>>> when
>>>>> can we get start on it? In my opinion, we need to start it right from
>>>> this
>>>>> moment.
>>>>> 
>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on the
>>> same
>>>>> topic [1] in July this year. I summarize his points here if you are
>>> too
>>>>> impatient to read through the contents of his email :p:
>>>>> 
>>>>> 1. Need to enhance the current extension mechanism
>>>>> 2. Need to enhance the code base for better maintenance
>>>>> 3. Need to support async
>>>>> 4. Need to decouple registry server and config server
>>>>> 5. Need to support Java8 and above so that we can use advanced
>>> features
>>>> in
>>>>> Dubbo's core
>>>>> 
>>>>> I agree with most of his points in this good proposal.
>>>>> 
>>>>> Here I'd like to initial a discussion on how we define Dubbo 3.0, or
>>> in
>>>> the
>>>>> other word, how do the community expect from Dubbo 3.0. In my
>>> opinion, I
>>>>> think we need to answer the following questions in this major release:
>>>>> 
>>>>> - Today the boundary between messaging and remoting call gets blur. We
>>>> may
>>>>> need to consider to support streaming at the protocol level.
>>>>> - Reative programming and its fundamental FP start to get adopted. We
>>>>> should consider to support it.
>>>>> - Dubbo should be redesigned to support async better, and treats
>>> async as
>>>>> the first class citizen. We do support async feature in 2.7.0 release
>>> but
>>>>> it is not so perfect.
>>>>> - Micro-services has been widely adopted. How Dubbo works seamlessly
>>> with
>>>>> micro-services becomes a question mark. We need to look into the
>>> inter-op
>>>>> between Dubbo and micro-services's registry server/config server. The
>>>>> support on separating registry server and config server in 2.7.0
>>> release
>>>> is
>>>>> a good start, but there are still lots of further works remaining
>>> with no
>>>>> doubt.
>>>>> - Once we conquer seamless micro-services support, we still need to
>>> take
>>>>> one step further to think about K8S integration. After all, K8S and
>>>> service
>>>>> mesh built above it are now considered the best way for micro-services
>>>>> deployment.
>>>>> - How we define mini-dubbo, or phrase in another way, what the minimal
>>>>> feature set we should define for Dubbo framework. The reason behind
>>> this
>>>>> is, it is very helpful for developing more language supports from the
>>>>> community. This also means, we need to modularize Dubbo further, to
>>> make
>>>> it
>>>>> a reference implementation for other languages.
>>>>> 
>>>>> In short, I suggest we need to focus on streaming protocol, Rx/FP,
>>> native
>>>>> async, micro-services support, refactor/modularize areas. Of course,
>>>> there
>>>>> are more I don't mention in this email, for examples: how we make
>>> Dubbo
>>>>> more resilient? how we support HTTP/2? and more.
>>>>> 
>>>>> Pls. let me know your opinion on what I and Liujie proposed, and share
>>>> your
>>>>> thought on what kind of features really matter to you.
>>>>> 
>>>>> Thanks,
>>>>> -Ian.
>>>>> 
>>>>> 
>>>>> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
>>>>> dev@dubbo.apache.org
>>>>> 
>>>> 
>>> 
>> 

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

[yuneng xie <xi...@gmail.com>]

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 <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：

> Hi Ian Luo,
>
> OK, i'd start to work on it soon.
>
> Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：
>
>> Hi Yuneng,
>>
>> Sounds interesting. I am especially interested in reactive programming
>> support. Pls. go ahead to try implement it on 3.x branch.
>>
>> Thanks,
>> -Ian.
>>
>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com> wrote:
>>
>> > Hi folks,
>> >
>> > I agreed with Ian Luo on the improvement list. I also got some idea in
>> my
>> > mind.  I'd just share with you two points below in detail which i'm most
>> > interested in right now.
>> >
>> > 1. Upgrade  the core abstraction "Invoker", which works in sync mode,
>> to an
>> > abstraction works in async mode. then we can construct
>> > InvocationChain/FilterChain that works in async mode.  A core
>> abstraction
>> > works in async mode would simplify the sync/async logic. We  no longer
>> need
>> > to repeat the logic about sync-mode/async-mode in each ProtocolInvoker.
>> > ProtocolInvoker could concentrate on async logic and we could handle
>> > sync-mode invoke all in once by wrapping the AsyncInvocationChain into a
>> > SyncInvocationChain.
>> >
>> > 2. Support using stream-value (Fowable, Flux...)  as param/returnType.
>> > really a nice feature.
>> >
>> > Please let me known your opinion on my points. I'm also glad to just
>> give
>> > it a try and raise a pr.
>> >
>> >
>> >
>> > Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
>> >
>> > > Hi folks,
>> > >
>> > > Finally we managed to ramp down version 2.7.0 development, and
>> hopefully
>> > we
>> > > can start the vote in the early of the next week. But the main
>> purpose of
>> > > this email is not a release announcement. Instead, since we now have
>> > > bandwidth, let's consider and discuss what we should focus out from
>> many
>> > > stuff we want to do. For example, we may focus more on issue and pull
>> > > request on GitHub, or we may plan 2.7 minor releases immediately
>> after we
>> > > release 2.7.0. But today I'd like to bring up one longer term plan
>> which
>> > > I'm now caring most, that is, how we define what version 3.0 is? and
>> when
>> > > can we get start on it? In my opinion, we need to start it right from
>> > this
>> > > moment.
>> > >
>> > > I recalled Liujie Qin (@liujieqin) initialed the discussion on the
>> same
>> > > topic [1] in July this year. I summarize his points here if you are
>> too
>> > > impatient to read through the contents of his email :p:
>> > >
>> > > 1. Need to enhance the current extension mechanism
>> > > 2. Need to enhance the code base for better maintenance
>> > > 3. Need to support async
>> > > 4. Need to decouple registry server and config server
>> > > 5. Need to support Java8 and above so that we can use advanced
>> features
>> > in
>> > > Dubbo's core
>> > >
>> > > I agree with most of his points in this good proposal.
>> > >
>> > > Here I'd like to initial a discussion on how we define Dubbo 3.0, or
>> in
>> > the
>> > > other word, how do the community expect from Dubbo 3.0. In my
>> opinion, I
>> > > think we need to answer the following questions in this major release:
>> > >
>> > > - Today the boundary between messaging and remoting call gets blur. We
>> > may
>> > > need to consider to support streaming at the protocol level.
>> > > - Reative programming and its fundamental FP start to get adopted. We
>> > > should consider to support it.
>> > > - Dubbo should be redesigned to support async better, and treats
>> async as
>> > > the first class citizen. We do support async feature in 2.7.0 release
>> but
>> > > it is not so perfect.
>> > > - Micro-services has been widely adopted. How Dubbo works seamlessly
>> with
>> > > micro-services becomes a question mark. We need to look into the
>> inter-op
>> > > between Dubbo and micro-services's registry server/config server. The
>> > > support on separating registry server and config server in 2.7.0
>> release
>> > is
>> > > a good start, but there are still lots of further works remaining
>> with no
>> > > doubt.
>> > > - Once we conquer seamless micro-services support, we still need to
>> take
>> > > one step further to think about K8S integration. After all, K8S and
>> > service
>> > > mesh built above it are now considered the best way for micro-services
>> > > deployment.
>> > > - How we define mini-dubbo, or phrase in another way, what the minimal
>> > > feature set we should define for Dubbo framework. The reason behind
>> this
>> > > is, it is very helpful for developing more language supports from the
>> > > community. This also means, we need to modularize Dubbo further, to
>> make
>> > it
>> > > a reference implementation for other languages.
>> > >
>> > > In short, I suggest we need to focus on streaming protocol, Rx/FP,
>> native
>> > > async, micro-services support, refactor/modularize areas. Of course,
>> > there
>> > > are more I don't mention in this email, for examples: how we make
>> Dubbo
>> > > more resilient? how we support HTTP/2? and more.
>> > >
>> > > Pls. let me know your opinion on what I and Liujie proposed, and share
>> > your
>> > > thought on what kind of features really matter to you.
>> > >
>> > > Thanks,
>> > > -Ian.
>> > >
>> > >
>> > > 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
>> > > dev@dubbo.apache.org
>> > >
>> >
>>
>

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

[yuneng xie <xi...@gmail.com>]

Hi Ian Luo,

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

Ian Luo <ia...@gmail.com> 于2019年1月17日周四 下午2:01写道：

> Hi Yuneng,
>
> Sounds interesting. I am especially interested in reactive programming
> support. Pls. go ahead to try implement it on 3.x branch.
>
> Thanks,
> -Ian.
>
> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xi...@gmail.com> wrote:
>
> > Hi folks,
> >
> > I agreed with Ian Luo on the improvement list. I also got some idea in my
> > mind.  I'd just share with you two points below in detail which i'm most
> > interested in right now.
> >
> > 1. Upgrade  the core abstraction "Invoker", which works in sync mode, to
> an
> > abstraction works in async mode. then we can construct
> > InvocationChain/FilterChain that works in async mode.  A core abstraction
> > works in async mode would simplify the sync/async logic. We  no longer
> need
> > to repeat the logic about sync-mode/async-mode in each ProtocolInvoker.
> > ProtocolInvoker could concentrate on async logic and we could handle
> > sync-mode invoke all in once by wrapping the AsyncInvocationChain into a
> > SyncInvocationChain.
> >
> > 2. Support using stream-value (Fowable, Flux...)  as param/returnType.
> > really a nice feature.
> >
> > Please let me known your opinion on my points. I'm also glad to just give
> > it a try and raise a pr.
> >
> >
> >
> > Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
> >
> > > Hi folks,
> > >
> > > Finally we managed to ramp down version 2.7.0 development, and
> hopefully
> > we
> > > can start the vote in the early of the next week. But the main purpose
> of
> > > this email is not a release announcement. Instead, since we now have
> > > bandwidth, let's consider and discuss what we should focus out from
> many
> > > stuff we want to do. For example, we may focus more on issue and pull
> > > request on GitHub, or we may plan 2.7 minor releases immediately after
> we
> > > release 2.7.0. But today I'd like to bring up one longer term plan
> which
> > > I'm now caring most, that is, how we define what version 3.0 is? and
> when
> > > can we get start on it? In my opinion, we need to start it right from
> > this
> > > moment.
> > >
> > > I recalled Liujie Qin (@liujieqin) initialed the discussion on the same
> > > topic [1] in July this year. I summarize his points here if you are too
> > > impatient to read through the contents of his email :p:
> > >
> > > 1. Need to enhance the current extension mechanism
> > > 2. Need to enhance the code base for better maintenance
> > > 3. Need to support async
> > > 4. Need to decouple registry server and config server
> > > 5. Need to support Java8 and above so that we can use advanced features
> > in
> > > Dubbo's core
> > >
> > > I agree with most of his points in this good proposal.
> > >
> > > Here I'd like to initial a discussion on how we define Dubbo 3.0, or in
> > the
> > > other word, how do the community expect from Dubbo 3.0. In my opinion,
> I
> > > think we need to answer the following questions in this major release:
> > >
> > > - Today the boundary between messaging and remoting call gets blur. We
> > may
> > > need to consider to support streaming at the protocol level.
> > > - Reative programming and its fundamental FP start to get adopted. We
> > > should consider to support it.
> > > - Dubbo should be redesigned to support async better, and treats async
> as
> > > the first class citizen. We do support async feature in 2.7.0 release
> but
> > > it is not so perfect.
> > > - Micro-services has been widely adopted. How Dubbo works seamlessly
> with
> > > micro-services becomes a question mark. We need to look into the
> inter-op
> > > between Dubbo and micro-services's registry server/config server. The
> > > support on separating registry server and config server in 2.7.0
> release
> > is
> > > a good start, but there are still lots of further works remaining with
> no
> > > doubt.
> > > - Once we conquer seamless micro-services support, we still need to
> take
> > > one step further to think about K8S integration. After all, K8S and
> > service
> > > mesh built above it are now considered the best way for micro-services
> > > deployment.
> > > - How we define mini-dubbo, or phrase in another way, what the minimal
> > > feature set we should define for Dubbo framework. The reason behind
> this
> > > is, it is very helpful for developing more language supports from the
> > > community. This also means, we need to modularize Dubbo further, to
> make
> > it
> > > a reference implementation for other languages.
> > >
> > > In short, I suggest we need to focus on streaming protocol, Rx/FP,
> native
> > > async, micro-services support, refactor/modularize areas. Of course,
> > there
> > > are more I don't mention in this email, for examples: how we make Dubbo
> > > more resilient? how we support HTTP/2? and more.
> > >
> > > Pls. let me know your opinion on what I and Liujie proposed, and share
> > your
> > > thought on what kind of features really matter to you.
> > >
> > > Thanks,
> > > -Ian.
> > >
> > >
> > > 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > > dev@dubbo.apache.org
> > >
> >
>

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

[Ian Luo <ia...@gmail.com>]

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 <xi...@gmail.com> wrote:

> Hi folks,
>
> I agreed with Ian Luo on the improvement list. I also got some idea in my
> mind.  I'd just share with you two points below in detail which i'm most
> interested in right now.
>
> 1. Upgrade  the core abstraction "Invoker", which works in sync mode, to an
> abstraction works in async mode. then we can construct
> InvocationChain/FilterChain that works in async mode.  A core abstraction
> works in async mode would simplify the sync/async logic. We  no longer need
> to repeat the logic about sync-mode/async-mode in each ProtocolInvoker.
> ProtocolInvoker could concentrate on async logic and we could handle
> sync-mode invoke all in once by wrapping the AsyncInvocationChain into a
> SyncInvocationChain.
>
> 2. Support using stream-value (Fowable, Flux...)  as param/returnType.
> really a nice feature.
>
> Please let me known your opinion on my points. I'm also glad to just give
> it a try and raise a pr.
>
>
>
> Ian Luo <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：
>
> > Hi folks,
> >
> > Finally we managed to ramp down version 2.7.0 development, and hopefully
> we
> > can start the vote in the early of the next week. But the main purpose of
> > this email is not a release announcement. Instead, since we now have
> > bandwidth, let's consider and discuss what we should focus out from many
> > stuff we want to do. For example, we may focus more on issue and pull
> > request on GitHub, or we may plan 2.7 minor releases immediately after we
> > release 2.7.0. But today I'd like to bring up one longer term plan which
> > I'm now caring most, that is, how we define what version 3.0 is? and when
> > can we get start on it? In my opinion, we need to start it right from
> this
> > moment.
> >
> > I recalled Liujie Qin (@liujieqin) initialed the discussion on the same
> > topic [1] in July this year. I summarize his points here if you are too
> > impatient to read through the contents of his email :p:
> >
> > 1. Need to enhance the current extension mechanism
> > 2. Need to enhance the code base for better maintenance
> > 3. Need to support async
> > 4. Need to decouple registry server and config server
> > 5. Need to support Java8 and above so that we can use advanced features
> in
> > Dubbo's core
> >
> > I agree with most of his points in this good proposal.
> >
> > Here I'd like to initial a discussion on how we define Dubbo 3.0, or in
> the
> > other word, how do the community expect from Dubbo 3.0. In my opinion, I
> > think we need to answer the following questions in this major release:
> >
> > - Today the boundary between messaging and remoting call gets blur. We
> may
> > need to consider to support streaming at the protocol level.
> > - Reative programming and its fundamental FP start to get adopted. We
> > should consider to support it.
> > - Dubbo should be redesigned to support async better, and treats async as
> > the first class citizen. We do support async feature in 2.7.0 release but
> > it is not so perfect.
> > - Micro-services has been widely adopted. How Dubbo works seamlessly with
> > micro-services becomes a question mark. We need to look into the inter-op
> > between Dubbo and micro-services's registry server/config server. The
> > support on separating registry server and config server in 2.7.0 release
> is
> > a good start, but there are still lots of further works remaining with no
> > doubt.
> > - Once we conquer seamless micro-services support, we still need to take
> > one step further to think about K8S integration. After all, K8S and
> service
> > mesh built above it are now considered the best way for micro-services
> > deployment.
> > - How we define mini-dubbo, or phrase in another way, what the minimal
> > feature set we should define for Dubbo framework. The reason behind this
> > is, it is very helpful for developing more language supports from the
> > community. This also means, we need to modularize Dubbo further, to make
> it
> > a reference implementation for other languages.
> >
> > In short, I suggest we need to focus on streaming protocol, Rx/FP, native
> > async, micro-services support, refactor/modularize areas. Of course,
> there
> > are more I don't mention in this email, for examples: how we make Dubbo
> > more resilient? how we support HTTP/2? and more.
> >
> > Pls. let me know your opinion on what I and Liujie proposed, and share
> your
> > thought on what kind of features really matter to you.
> >
> > Thanks,
> > -Ian.
> >
> >
> > 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> > dev@dubbo.apache.org
> >
>

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

[yuneng xie <xi...@gmail.com>]

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 <ia...@gmail.com> 于2019年1月10日周四 下午6:00写道：

> Hi folks,
>
> Finally we managed to ramp down version 2.7.0 development, and hopefully we
> can start the vote in the early of the next week. But the main purpose of
> this email is not a release announcement. Instead, since we now have
> bandwidth, let's consider and discuss what we should focus out from many
> stuff we want to do. For example, we may focus more on issue and pull
> request on GitHub, or we may plan 2.7 minor releases immediately after we
> release 2.7.0. But today I'd like to bring up one longer term plan which
> I'm now caring most, that is, how we define what version 3.0 is? and when
> can we get start on it? In my opinion, we need to start it right from this
> moment.
>
> I recalled Liujie Qin (@liujieqin) initialed the discussion on the same
> topic [1] in July this year. I summarize his points here if you are too
> impatient to read through the contents of his email :p:
>
> 1. Need to enhance the current extension mechanism
> 2. Need to enhance the code base for better maintenance
> 3. Need to support async
> 4. Need to decouple registry server and config server
> 5. Need to support Java8 and above so that we can use advanced features in
> Dubbo's core
>
> I agree with most of his points in this good proposal.
>
> Here I'd like to initial a discussion on how we define Dubbo 3.0, or in the
> other word, how do the community expect from Dubbo 3.0. In my opinion, I
> think we need to answer the following questions in this major release:
>
> - Today the boundary between messaging and remoting call gets blur. We may
> need to consider to support streaming at the protocol level.
> - Reative programming and its fundamental FP start to get adopted. We
> should consider to support it.
> - Dubbo should be redesigned to support async better, and treats async as
> the first class citizen. We do support async feature in 2.7.0 release but
> it is not so perfect.
> - Micro-services has been widely adopted. How Dubbo works seamlessly with
> micro-services becomes a question mark. We need to look into the inter-op
> between Dubbo and micro-services's registry server/config server. The
> support on separating registry server and config server in 2.7.0 release is
> a good start, but there are still lots of further works remaining with no
> doubt.
> - Once we conquer seamless micro-services support, we still need to take
> one step further to think about K8S integration. After all, K8S and service
> mesh built above it are now considered the best way for micro-services
> deployment.
> - How we define mini-dubbo, or phrase in another way, what the minimal
> feature set we should define for Dubbo framework. The reason behind this
> is, it is very helpful for developing more language supports from the
> community. This also means, we need to modularize Dubbo further, to make it
> a reference implementation for other languages.
>
> In short, I suggest we need to focus on streaming protocol, Rx/FP, native
> async, micro-services support, refactor/modularize areas. Of course, there
> are more I don't mention in this email, for examples: how we make Dubbo
> more resilient? how we support HTTP/2? and more.
>
> Pls. let me know your opinion on what I and Liujie proposed, and share your
> thought on what kind of features really matter to you.
>
> Thanks,
> -Ian.
>
>
> 1. Proposal for Dubbo 3.0 from liujieqin@apache.org on
> dev@dubbo.apache.org
>