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
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.