Open neoaggelos opened 4 years ago
Well, the most important point here is that, apparently, compiling our current protocol buffers is not a straight-forward process for users. It is not realistic to attempt to provide compiled protocol buffers for all languages supported (officially or otherwise) by protoc, so we need to make the compilation process as simple as possible - hence, the suggestion is to generate clean, minimal protocol buffers (i.e. .proto
) files. In my opinion the wording in the OP is not completely clear on this point.
Please see https://github.com/TheThingsNetwork/lorawan-stack/pull/2978#issuecomment-665134388 for context and the proposal in it's entirety.
Are you proposing a) to have all protos that are used by lorawan-stack
in internal/api
, and generate clean protos (of external API) to api
or b) that all external API is in api
and only internal API is in internal/api
, i.e. that lorawan-stack
uses protos generated from api
too? I think option (b) is pretty problematic.
In any case, having clean, vanilla protos with no dependencies other than standard Protocol Buffers stuff in api
would be ideal. From there, we can generate to some popular languages, but if developers need their own for some exotic languages, they would be able to do that easily.
a.) In v4 we could try b.)
This is also why I suggest to have a tool, which would let us selectively choose entities to "export", we could also just separate these by filename, of course, or maybe write yet another protoc plugin, which would let us export not only specific structures/services, but also specific fields/methods, while keeping other ones hidden.
On Fri, Jul 31, 2020, 13:11 Johan Stokking notifications@github.com wrote:
Are you proposing a) to have all protos that are used by lorawan-stack in internal/api, and generate clean protos (of external API) to api or b) that all external API is in api and only internal API is in internal/api, i.e. that lorawan-stack uses protos generated from api too? I think option (b) is pretty problematic.
In any case, having clean, vanilla protos with no dependencies other than standard Protocol Buffers stuff in api would be ideal. From there, we can generate to some popular languages, but if developers need their own for some exotic languages, they would be able to do that easily.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/TheThingsNetwork/lorawan-stack/issues/3006#issuecomment-667046548, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCIAUMULQYAKJ73GDELFOLR6KKGBANCNFSM4PN227JQ .
Removing assignments and bumping back to triage for re-assignment and prioritization.
Maybe this should be merged into a new "SDK" umbrella issue?
cc: @NicolasMrad
Summary
Generate for use in other languages, e.g. C/C++/Python
Why do we need this?
So developers can marshal/unmarshal protocol buffers, create SDKs,
What is already there? What do you see now?
Protocol buffers generated for Go in
pkg/ttnpb
What is missing? What do you want to see?
Protocol buffers for other languages
Environment
3.8.7
How do you propose to implement this?
From https://github.com/TheThingsNetwork/lorawan-stack/pull/2978#issuecomment-665134388:
Can you do this yourself and submit a Pull Request?
No