On 04/21/2011 03:23 PM, Brian Stansberry wrote:
On 4/21/11 3:01 AM, Heiko Braun wrote:
>
> Both variants are fine. I can also understand the attempt to
> distinguish operation vs attribute use cases.
>
> IMO this reveals one of the weak sports in the detyped API:
> runtime vs. configuration properties of the system.
>
> to further distinguish these two I would suggest the following,
> which may apply to other subsystems as well:
>
> - if changing the configuration impacts the runtime state (i.e.
enabled->disabled)
> then make it an operation
> - if it's merely configuration then make it an attribute
>
I'm fine with this, but let's clarify what "impacts the runtime state"
means. Many configuration changes will impact the runtime state. Instead
of "impacts the runtime state" I'd say "results in an MSC service
starting or stopping." That's the main case where an action has rippling
effects the user might not anticipate
Yup exactly. For example some of RW attribute exposed by JCA change
runtime state. In particulare there are some Pool configuration that
changes at runtime without any service restart required, like
max-pool-size or min-pool-size
S.