[featrue] Proto IDL control platform Implementation

[kaori-seasons]

hi community. For Proto IDL control platform design. I suggest splitting the tasks into the following parts and trying to complete them

• Dubbo realizes uploading proto files on the provider side and downloading proto files on the consumer side [doing]
• dubbo-admin implements schema upload interface and basic version management interface
• dubbo-admin implements maven-based jar package remote management
• dubbo-admin implements protobuf syntax verification
• dubbo-admin implements timely compilation of proto files based on janino

In the near future, I will discuss 1 or 2 tasks with @LXPWing conducting collaborative research

[EarthChen]

I understand that the upload and download of pb should not be implemented by dubbo?

[kaori-seasons]

I understand that the upload and download of pb should not be implemented by dubbo?

@EarthChen @AlbumenJ
In my opinion, pushing proto and obtaining proto structure need to be done based on the IDL client, while the IDL client needs to be integrated in the dubbo provider and consumer by configuring the dubbo admin address

I think that an entry for uploading proto files should be added in dubbo-admin, and then the SchemaController is defined here, and the provider and consumer register or call the rest interface.

To sum up, I think it is necessary to change the logic of the dubbo-provider and dubbo-consumer modules. Of course, if you think there is something inappropriate, you can raise it in time. I am also tracking the relevant details these days.

[EarthChen]

I understand that the upload and download of pb should not be implemented by dubbo?

In my opinion, pushing proto and obtaining proto structure need to be done based on the IDL client, while the IDL client needs to be integrated in the dubbo provider and consumer by configuring the dubbo admin address

I think that an entry for uploading proto files should be added in dubbo-admin, and then the SchemaController is defined here, and the provider and consumer register or call the rest interface.

To sum up, I think it is necessary to change the logic of the dubbo-provider and dubbo-consumer modules. Of course, if you think there is something inappropriate, you can raise it in time. I am also tracking the relevant details these days.

I think it is more appropriate for dubbo to directly use the jar package of the api generated by idl.

[EarthChen]

I understand that the upload and download of pb should not be implemented by dubbo?

In my opinion, pushing proto and obtaining proto structure need to be done based on the IDL client, while the IDL client needs to be integrated in the dubbo provider and consumer by configuring the dubbo admin address
I think that an entry for uploading proto files should be added in dubbo-admin, and then the SchemaController is defined here, and the provider and consumer register or call the rest interface.
To sum up, I think it is necessary to change the logic of the dubbo-provider and dubbo-consumer modules. Of course, if you think there is something inappropriate, you can raise it in time. I am also tracking the relevant details these days.

I think it is more appropriate for dubbo to directly use the jar package of the api generated by idl.

For java users, it is rare to use idl directly for generation.

[kaori-seasons]

我理解pb的上傳下載應該不是dubbo實現的吧？

在我看來，推送proto和獲取proto結構需要基於IDL client，而IDL client 需要在dubbo provider和consumer中集成，通過配置dubbo admin地址
我覺得應該在dubbo中增加一個上傳proto文件的入口-admin，然後這裡定義了SchemaController ，提供者和消費者註冊或者調用rest接口。
綜上所述，我認為有必要改變dubbo-provider和dubbo-consumer模塊的邏輯。當然，如果大家覺得有什麼不妥的地方，可以及時提出來。我這幾天也在跟踪相關的細節。

我覺得dubbo直接使用idl生成的api的jar包比較合適。

對於java用戶來說，很少直接使用idl來生成。

The purpose of this feature is to provide version management functions for users to use IDL + protobuf to implement cross-language definition scenarios.

The traditional way of use will have the following problems

1. When new parameters are added, the protobuf schema will be regenerated, which is inconvenient to manage
2. After the file is regenerated, the upstream and downstream interface types also need to be changed, which means manual copying to the upstream and downstream is not convenient for agile development
3. For enterprises, the application is started as a jar package. If you do not maintain the changed version of the protobuf file when you release the version, you will face continuous rollback and re-release, which is very expensive.

So we need this management and control platform to support things such as protobuf dynamic generation, file compilation, and publishing to remote warehouse management versions.

IMO, I don't quite understand what your intent is?