Open wj-Mcat opened 4 years ago
This leads to this problem in all multi-languages wechaty, not just in python-wechaty.
Short answer:
Long answer posted later shortly.
Long answer:
The wechaty-puppet
is the golden source of truth for all the child puppet classes (wechaty-puppet-xxx
) as long as we are working in the TypeScript environment.
The situation will be changed when we are not working under the TypeScript environments:
All the GRPC Service is based on the Protocol Buffer definition file, this file will define everything about the Puppet API and all the constraints (like MESSAGE_TYPE_ATTACHMENT
)
When we are working with the GRPC service, we must map everything that we have from local to the Protocol Buffer defined values.
And as we discussed before, for a higher perspective of the Wechaty ecosystem, we will treat the Protocol Buffer values as the true Golden Source of Truth. (above all languages, including TS)
Maybe we should call our TypeScript Puppet Silver Source of Truth
Multi-lang Wechaty means Python, Java, and Go (Non-TS) Wechaty.
When Multi-lang Wechaty is working with the GRPC Service, we should convert all values from the GRPC service to the local value, so that we can make sure everything is right.
As we discussed before, the best way to use those values for our Multi-lang Wechaty is that we do not define locally. Instead of locally define them, we use all defined values from the GRPC Stub file because they can be auto-generated from the Protocol Buffer, which will be always synced with our Golden Source of Truth: Protocol Buffer.
Convert everything from local to GRPC, then from GRPC to local. You can think what we are doing is as same as the socket API functions: htons()
, htonl()
, ntohs()
, ntohl()
.
Yes, wechaty-puppet
should be golden truth for all wechaty-puppet-*
. I strongly agree with that.
The reason why I create this issu is that hostie-server follow ts-wechaty-puppet
data structure. which may lead multi-language wechaty must complete the mapping
process. The MessagPayload's MessageType from the hostie-server
follow the truth of the ts-wechaty-puppet
, so, I begin to think about that whether wechaty-puppet
is the final Golden Truth, which may be modified at eariler stage. All multi-language wechaty is at early stage, so as the wechaty-puppet
golden truth. This is my consideration.
And completing the mapping
process is ok for us. After you explaination, I think we should try to keep the Golden Truth
of the wechaty-puppet.
Thanks for such a insightful analytics. I'll review the related code in details later.
I am testing .net with Wechaty.Grpc
nuget package, and I hit the similar issue that, the MessageType.MiniProgram
in github.wechaty.grpc.puppet
are not map the reponse.
For server response, it will return 9 for mini program, and the MessageType.MiniProgram
in github.wechaty.grpc.puppet
is 10.
In addition, sometimes it will return 0 for miniprogram.
I am test with wechaty-puppet-donut
.
https://github.com/Chatie/grpc/blob/4c32075f391c29407a9ace0fb6c8765097277bb1/proto/wechaty/puppet/message.proto#L9-L26
This does not match the
MessageType
definition in wechaty-puppet, and we found this during testing. Tests show that wechaty-puppet's data type definition is correct.