Naming of new provider to be submitted

[Philip Brown]

The good news is, I hope to have a new type/provider combo to submit to the puppet source next week :) Seems like I'm making good progress.

The bad news is, I now need to pick a name that's going to be good for the long haul, before I submit it :) So I'm asking here for suggestions.

 

I'm writing this for what is,as far as I know, a somewhat OS specific feature at the moment. However, perhaps there are vaguely similar features in other OS's I'm not familiar with.

Hmm. In some ways, I suppose it's similar to "windows registry". Very similar, really.

But at any rate, the particular itch I'm scratching, is I'm writing a module to support what I'd call solaris "system properties", or more SMF properties.

Any SMF service,   svc:/system/whatever/blah, can have associated "properties" registered along with it.There are some generic properties, and also some service specific properties.

For example, most active services tend to have a property named "start/timeout_seconds".

It is thus useful to have support, not to install a "new" service, but to finetune existing, already installed system services, with these properties.

I thought that I'd use a somewhat portable name, type "sysprop".

"systemproperties" seems a bit unwieldy to me, but I dunno.  What do you guys think?

(FYI, the solaris manpages describe these properties as,

 "properties in the service configuration repository")

[Luke Kanies]

First, is there a reason not to just maintain this as a module on the forge?

We're trying to keep the builtin types to the minimum that most people will use, and are even doing things like moving the Nagios types to a module, rather than shipping them in core.

Regardless, though, I agree the name is important.  Most people would agree I'm not the best person to give advice on names, but I'd go with something like svcproperties.

-- 

Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199

[Philip Brown]

On Saturday, May 5, 2012 1:40:36 PM UTC-7, Luke Kanies wrote:

First, is there a reason not to just maintain this as a module on the forge?

We're trying to keep the builtin types to the minimum that most people will use, and are even doing things like moving the Nagios types to a module, rather than shipping them in core.

sounds fine to me.. once I learn how to do that :)

 

Regardless, though, I agree the name is important.  Most people would agree I'm not the best person to give advice on names, but I'd go with something like svcproperties.

it does seem to have potential overlap with windows registry types, though. So while "sysproperties" could work with that, "svcproperties" would not, seems to me.

If it makes sense to have this class shared between those two uses. I dunno.

Any ms-windows developers reading this?

[David Schmitt]

On 2012-05-06 00:44, Philip Brown wrote:
> it does seem to have potential overlap with windows registry types,
> though. So while "sysproperties" could work with that, "svcproperties"
> would not, seems to me.
> If it makes sense to have this class shared between those two uses. I dunno.
> Any ms-windows developers reading this?

Is there anything internally or externally valuable in conflating
svcproperties and registry entries?

Ask yourself the following questions:

* Do the different systems have the same parameters?

* Will it allow code-sharing? e.g. Do the two share a common
key-syntax which can be checked in the Type, while the provider
only manage read/write to the storage.

* Could Linux' sysctl code be integrated too?

* Can the Type provide a useful abstraction?

* Could the same abstraction be provided as a module wrapping the
low-level types?

I've ordered the questions somewhat. If any of them should be answered
no, it'd be an indication that separate types would be the way to go.


Best Regards, David

[Philip Brown]

On Sunday, May 6, 2012 10:48:31 PM UTC-7, David Schmitt wrote:

On 2012-05-06 00:44, Philip Brown wrote:
> it does seem to have potential overlap with windows registry types,
> though. So while "sysproperties" could work with that, "svcproperties"
> would not, seems to me.
> If it makes sense to have this class shared between those two uses. I dunno.
> Any ms-windows developers reading this?

Is there anything internally or externally valuable in conflating
svcproperties and registry entries?

Ask yourself the following questions:

   * Do the different systems have the same parameters?

   * Will it allow code-sharing? e.g. Do the two share a common
     key-syntax which can be checked in the Type, while the provider
     only manage read/write to the storage.

   * Could Linux' sysctl code be integrated too?

   * Can the Type provide a useful abstraction?

   * Could the same abstraction be provided as a module wrapping the
     low-level types?

Trouble is, I dont know the answer to these things. I dont know linux sysctl. I dont DEEPLY know windows registry stuff

(although the light level I know of, seems to be pretty analogous)

(A quick read of the linux manpage for "sysctl", however, tell me that that is different. sysctl seems to be "only" for kernel parameters, whereas what I'm writing, is parameters for userland services)

 Given the potential confusion on naming for linux "sysctl" and related stuff, I'm now thinking that the naming for my module is better named as "svcprop", though.