Reason for the Feature
See #4588 for some background. That one is about analyzers, but is adjacent to client generation.
As a developer using Microservices,
In order to control exactly what goes into my MS client code,
I want clear, understandable configuration options for [Callable]s and such.
Proposed Solution/Requirements
The SDK should choose reasonable defaults for client-generation attributes: for example [Callable]s should generate client methods, but [AdminOnlyCallable]s shouldn't. However, it should be possible for developers to override the behavior on a method-by-method basis, either using an argument to the Callable-like attribute or using another attribute alongside it. It should be possible to go both directions: disable generation of default-yes stuff AND enable generation of default-no stuff.
Alternatives or Workarounds
Currently the generation criteria seem to be implicit in the class hierarchy: [Callable] and [ClientCallable] get generation, but [AdminOnlyCallable] and [ServerCallable] do not.
Reason for the Feature
See #4588 for some background. That one is about analyzers, but is adjacent to client generation.
As a developer using Microservices,
In order to control exactly what goes into my MS client code,
I want clear, understandable configuration options for [Callable]s and such.
Proposed Solution/Requirements
The SDK should choose reasonable defaults for client-generation attributes: for example
[Callable]s should generate client methods, but[AdminOnlyCallable]s shouldn't. However, it should be possible for developers to override the behavior on a method-by-method basis, either using an argument to the Callable-like attribute or using another attribute alongside it. It should be possible to go both directions: disable generation of default-yes stuff AND enable generation of default-no stuff.Alternatives or Workarounds
Currently the generation criteria seem to be implicit in the class hierarchy:
[Callable]and[ClientCallable]get generation, but[AdminOnlyCallable]and[ServerCallable]do not.