Do we need to build our golang model package?

[SamYuan1990]

The advantage and disadvantage for set up a model package for admin-sdk:
we can define a model just for admin-sdk which provide conveniences as we can share this model across admin sdk packages. But it will add external workload for us as convert model to fabric proto
for ex:
https://hyperledger.github.io/fabric-protos/protos.html#lifecycle-CommitChaincodeDefinitionArgs
https://hyperledger.github.io/fabric-protos/protos.html#lifecycle-ApproveChaincodeDefinitionForMyOrgArgs
https://hyperledger.github.io/fabric-protos/protos.html#lifecycle-CheckCommitReadinessArgs

[SamYuan1990]

@bestbeforetoday , @channingduan please free to leave your comments.

[bestbeforetoday]

I'm not sure what you mean by a model package here. Are you talking about defining protocol buffer messages specifically for the admin SDK?

Protocol buffer messages are useful for remote gRPC service invocations or perhaps for persistent storage since they can be efficiently serialized. I don't see why we would want to define any protocol buffer messages specific to the admin SDK.

We must use the protocol buffer messages Fabric expects when sending data to/from Fabric. Go language bindings these messages are already built and published in the fabric-protos-go-apiv2 module, so we should use them, not rebuild them again ourselves.