Replies: 6 comments 1 reply
-
Any capability extracted out to a separate repository should probably also operate on fabric-protos-go-apiv2, not on fabric-protos-go. |
Beta Was this translation helpful? Give feedback.
-
It would definitely be preferable to use apiv2 but I think that depends on where/when it gets extracted, and what consumes the separate module, e.g. fabric-lib-go would probably need to use the old bindings until other components catch up. |
Beta Was this translation helpful? Give feedback.
-
@jt-nti @bestbeforetoday Any progres on this issue? Or did I miss something great? |
Beta Was this translation helpful? Give feedback.
-
As far as I know, nobody is working on this. Somebody else might have better information. |
Beta Was this translation helpful? Give feedback.
-
@jt-nti @bestbeforetoday I have some free time to pick up this task recently, starting from here https://github.com/davidkhala/fabric-protoutil/, I copy the protoutil package to here and trying to isolating it from fabric core as much as possible. Welcome comment on direction |
Beta Was this translation helpful? Give feedback.
-
I've moved this to a Discussion. I agree in concept about moving protoutil to fabric-lib-go, that's the intended place for shared common code. The challenge is that it will pull in some other fabric dependencies. If you can manage that in a PR for review it would be appreciated. There is separate discussion about moving fabric repositories to APIv2 in #3650. I'd suggest to keep the two work items independent. Which one would you like to attempt first @davidkhala ? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
From @davidkhala hyperledger/fabric-protos-go#10
Perhaps fabric-lib-go would be a good home, and some thought about what to move is probably required since protoutil is currently a bit of a mixed bag.
Beta Was this translation helpful? Give feedback.
All reactions