+1 from my side on this.
I might be thinking loud here, please correct me if requires correction :).
I am planning to look into developer community to come up with some data
point which can help us
1. What are the convention or configuration approach developer are
using more and how. This is to see what convention, approach are mostly
followed and how far is dubbo from the line.
2. Developer, Dev-ops and Support point of view what user is looking
or using from micro service architecture.
I might have misses something here (please add valuable missing points
which you know and I missed :) ).
Does the above approach looks ok to community?
On Thu, Dec 27, 2018 at 12:24 PM jun liu <[email protected]> wrote:
> > I am really appreciated that someone brings up this topic, dev
> experience.
> > I think we could set up this as the major theme for the next releases.
>
> +1, I think we can start a Github Project to track this topic.
>
> > I am a fan of one liner, and I am thinking it might be a good idea to
> > introduce a chained API to allow user to start up a simple Dubbo
> > application in just one line. Unfortunately I am always occupied by other
> > works and have no chance to build it.
>
> To make things happen, I think we should first list all possible aspects
> that worth urgent improvement. Then add them to the next release milestone
> according to priority. Think of possible solutions in detail and discuss
> each of them in a separated thread.
> I think the Committers and PPMCs should be responsible for starting things
> up.
>
> > - get rid of camel style attribute name and switched to 'dash' separated
> > attribute name
>
> I think camel or dash, which style should be used, should depends on the
> configuration method we use. It's easy to find how some popular frameworks
> set their configuration format, usually these conventions are followed by
> most developers and even are facto standards.
>
> Now, I decide to write a blog introducing Dubbo’s configuration
> conventions and all the possible configuration items available in Dubbo.
>
> > - consider to introduce delegated schema for different protocol
> > implementation.
>
> Could you describe this in depth? I failed to get your point.
>
> Jun
>
> > On Dec 25, 2018, at 1:53 PM, Ian Luo <[email protected]> wrote:
> >
> > I am really appreciated that someone brings up this topic, dev
> experience.
> > I think we could set up this as the major theme for the next releases.
> >
> > I am a fan of one liner, and I am thinking it might be a good idea to
> > introduce a chained API to allow user to start up a simple Dubbo
> > application in just one line. Unfortunately I am always occupied by other
> > works and have no chance to build it.
> >
> > Besides chained API, I suggest we should look into XML schema further, at
> > least we need to enhance the following areas:
> >
> > - get rid of camel style attribute name and switched to 'dash' separated
> > attribute name
> > - consider to introduce delegated schema for different protocol
> > implementation.
> >
> > Thanks,
> > -Ian.
> >
> >
> >
> > On Fri, Dec 21, 2018 at 4:30 PM jun liu <[email protected]> wrote:
> >
> >> Hi, All
> >>
> >>
> >>
> 最近收到了一些用户和开发者反馈，总结起来我觉得主要是Dubbo框架在开发态和运行态能力的一些欠缺。因此，除了我们经常提及的如何围绕Dubbo构建更丰富的微服务开发解决方案外，我个人觉得我们应该在核心框架的易用性上也应多投入一些精力，为用户提供更好的开发使用体验。
> >>
> >> 以下是我当前能想到的一些点，从我的认识中肯定还有很多需要优化的地方，我一时没能想起来，如果你觉得有亟需改进的地方，欢迎补充。
> >>
> >> 首先，开发层面。
> >> 1. 注解方式增强和bug修复，汇总和修复报告的issue，数量应该还挺多
> >> 2. 注解能力和XML、properties对齐，如方法级配置等
> >> 3. Dubbo配置格式的统一、增加面向用户的配置使用说明、配置项汇总等
> >> 4. API编程接口易用性的优化
> >> 5. 汇总和解决其他一些涉及到开发效率或易用性的issue报告
> >>
> >> 其次，运维层面。
> >> 1. OPS功能进一步丰富
> >> 2. Metrics
> >> 3. 内部配置和运行态数据采集并尝试通过各种Endpoints暴露等
> >> 4. Telnet指令丰富/增强
> >>
> >> 大家经常遇到问题的几个场景的blog输出
> >> 1. 优雅停机
> >> 2. 其他
> >>
> >> 其他需要补充的...
> >>
> >> Translated from Google:
> >>
> >> I have recently received some user and developer feedback. In summary, I
> >> think it is mainly due to the lack of development and runtime
> capabilities
> >> of the Dubbo framework. Therefore, in addition to how we often discuss
> how
> >> to build a richer microservice development solution around Dubbo, I
> >> personally feel that we should put more effort into the core framework
> to
> >> provide users with a better development experience.
> >>
> >> The following are some of the points that I can think of right now.
> There
> >> are definitely a lot of things that I need to optimize from my
> >> understanding. I can't think of it for a while. If you feel that there
> is a
> >> need for improvement, welcome to add.
> >>
> >> Firstly, development level.
> >> 1. Annotation enhancements and bug fixes, summary and fix report issues
> >> 2. Annotation capability and XML, properties alignment, such as method
> >> level configuration, etc.
> >> 3. Uniform configuration of Dubbo, increase user-oriented configuration
> >> instructions, and summary of configuration items
> >> 4. Optimization of the ease of use of the API programming interface
> >> 5. Summarize and resolve other issue reports that involve development
> >> efficiency or ease of use
> >>
> >> Secondly, operation and maintenance level.
> >> 1. OPS function is further enriched
> >> 2. Metrics
> >> 3. Internal configuration and operational state data acquisition and
> >> attempt to expose through various Endpoints, etc.
> >> 4. Telnet command rich/enhanced
> >>
> >> Last but not least, anything you think important regarding development
> >> experiences.
> >>
> >> Jun
> >>
> >>
>
>
