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
If separated like this, attributes names should not imply state
changes.
For instance,
a) setting the attribute "enabled" to false, make me think
b ) I "disable" the resource.
Whereas a) is an attribute change but b) is an operation.
We can solve the problem for the datasource by keeping the enable/disable operations like
they are
and simply rename the attribute to something like "auto-start". We have a
similar case with server-instances.
Ike
On Apr 21, 2011, at 4:37 AM, Brian Stansberry wrote:
> I think offering both variants is fine too.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat