Nice to see this proposal of yours, but it seems a bit like what rocketmq-spring[1] does, so can you elaborate on the difference between QSF and rocketmq-spring?
[1]https://github.com/apache/rocketmq-spring yukon <yu...@apache.org> 于2022年3月16日周三 20:23写道： > Could you please provide some demos to show how we use > QSFProducer/Consumer? > > On Wed, Mar 16, 2022 at 6:49 PM Jason.Chen <chenhua...@foxmail.com> wrote: > > > I am sorry that the RIP mail format is incorrect, and i write a > > well-formed google doc version here: > > > > > > > https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg > > > > > > > > > > > > > > RIP 35 queue service framework(QSF) > > > > Status > > > > ● Current State: Proposed > > > > ● Authors: booom( booom (jason) · GitHub) > > > > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub) > > > > ● Mailing List discussion: dev@rocketmq.apache.org > > > > ● Pull Request: > > > > ● Released: > > > > Background & Motivation > > > > What do we need to do > > > > ● Will we add a new module? Yes. > > > > ● Will we add new APIs? No. > > > > ● Will we add new feature? Yes. > > > > Why should we do that > > > > ● Are there any problems of our current project? > > > > The current mq client API is intrusive, to send message or consume > > message, we should code to manage the mq infrastructure, and mixed it up > > with our business logic codes. > > > > ● What can we benefit proposed changes? > > > > 1. Encapsulate mq client API to support method invoking style usage. > > > > 2. The encapsulation is easily extensible, to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > 3. Isolate the mq client manage code and the business logic code, to > > help mq users improve their systems’ maintainability. > > > > Goals > > > > ● What problem is this proposal designed to solve? > > > > Unobtrusive mq client usage, and easily extensible to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > ● To what degree should we solve the problem? > > > > 100%. > > > > Non-Goals > > > > ● What problem is this proposal NOT designed to solve? > > > > 1. Add new features to classics mq client. > > > > 2. Affect compatibility. > > > > ● Are there any limits of this proposal? > > > > Only QSF(queue service framework) users will benefit. > > > > Changes > > > > Architecture > > > > To simplify a process, we need to consider what information is essential > > and must be provided by users to execute this process? How to properly > > organize this information so that it is most user-friendly? > > > > > > Along this thinking path, we have extracted the necessary parameters for > > mq calls and organized them into the java annotations @QSFConsumer and > > @QSFProvider. After that, through the extension support of spring > container > > in each stage of bean life cycle, we can process @QSFConsumer > @QSFProvider > > annotation in BeanPostProcessor, extract method invocation information to > > method invocation information object MethodInvokeInfo and send it out, > and > > locate it through MethodInvokeInfo at the message receiving endpoint. The > > bean where the call is made, the method where it is located, the > parameters > > used, and then the method is called by reflection. > > > > > > > > > > > > Interface Design/Change > > > > ● Method signature changes > > > > ○ method name > > > > ○ parameter list > > > > ○ return value > > > > Nothing. > > > > ● Method behavior changes > > > > Nothing. > > > > ● CLI command changes > > > > Nothing. > > > > ● Log format or content changes > > > > Nothing. > > > > Compatibility, Deprecation, and Migration Plan > > > > ● Are backward and forward compatibility taken into > > consideration? > > > > Yes. > > > > ● Are there deprecated APIs? > > > > Nothing. > > > > ● How do we do migration? > > > > Upgrade normally, no additional migration required. > > > > Implementation Outline > > > > We will implement the proposed changes by 1 phase. (QSF is implemented > and > > works well in our project) > > > > Phase 1 > > > > > > Complete the QSF mq client encapsulation. > > > > > > > > Complete the QSF idempotency support > > > > > > Rejected Alternatives > > > > There are no other alternatives. > > > > > > > > > > > > > > > > ------------------ 原始邮件 ------------------ > > 发件人: > > "Jason.Chen" > > < > > chenhua...@foxmail.com>; > > 发送时间: 2022年3月16日(星期三) 中午12:55 > > 收件人: "dev"<dev@rocketmq.apache.org>; > > > > 主题: [DISCUSS] RIP-35 queue service framework(QSF) > > > > > > > > > > > > > > > > Status > > > > ● Current State: Proposed > > > > ● Authors: booom( booom (jason) · GitHub) > > > > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub) > > > > ● Mailing List discussion: > > dev@rocketmq.apache.org > > > > ● Pull Request: > > > > ● Released: <relased_version> > > > > Background & Motivation > > > > What do we need to do > > > > ● Will we add a new module? Yes. > > > > ● Will we add new APIs? No. > > > > ● Will we add new feature? Yes. > > > > Why should we do that > > > > ● Are there any problems of our current project? > > > > The current mq client API is intrusive, to send message or consume > > message, we should code to manage the mq infrastructure, and mixed it up > > with our business logic codes. > > > > ● What can we benefit proposed changes? > > > > 1. Encapsulate mq client API to support method > invoking > > style usage. > > > > 2. The encapsulation is easily extensible, to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > 3. Isolate the mq client manage code and the business > > logic code, to help mq users improve their systems’ maintainability. > > > > > > > > Goals > > > > ● What problem is this proposal designed to > solve? > > > > Unobtrusive mq client usage, and easily extensible to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > ● To what degree should we solve the problem? > > > > 100%. > > > > Non-Goals > > > > ● What problem is this proposal NOT designed to > > solve? > > > > 1. Add new features to classics mq client. > > > > 2. Affect compatibility. > > > > ● Are there any limits of this proposal? > > > > Only QSF(queue service framework) users will benefit. > > > > Changes > > > > Architecture > > > > Interface Design/Change > > > > ● Method signature changes > > > > ○ method name > > > > ○ parameter list > > > > ○ return value > > > > Nothing. > > > > ● Method behavior changes > > > > Nothing. > > > > ● CLI command changes > > > > Nothing. > > > > ● Log format or content changes > > > > Nothing. > > > > Compatibility, Deprecation, and Migration Plan > > > > ● Are backward and forward compatibility taken > > into consideration? > > > > Yes. > > > > ● Are there deprecated APIs? > > > > Nothing. > > > > ● How do we do migration? > > > > Upgrade normally, no additional migration required. > > > > Implementation Outline > > > > We will implement the proposed changes by 1 phase. (QSF is implemented > and > > works well in our project) > > > > Phase 1 > > > > Complete the QSF mq client encapsulation. > > > > Complete the QSF idempotency support > > > > Rejected Alternatives > > > > There are no other alternatives. >
