Quoth Antonello Cruz on Thu, Aug 28, 2008 at 01:38:04PM -0700:
> I'll try to re-work this paragraph and post it here later.
> For now, I am not comfortable with the term "templated" too, but that
> may be because English is not my first language...
I think "templated" would be ok if you defined it with something like
"We say properties are 'templated' by an entity when the entity's
properties contain patterns for the properties in question." Well
that's not very clear, but I hope expresses my idea.
> I am kind of struggling to find a different term for level. I thought of
> scope but I don't want to overload the term that is already used in SMF.
> At the lack of a better term (I am assuming you don't have any
> suggestions) I'll keep level but I'll try to give it some context.
"level" is ok, but assumes that the reader understands that the levels
will be combined. I think you can avoid it by saying that when template
information is used to validate configuration, first it is looked up in
X, then in Y, then in Z. Essentially what's in the second paragraph,
I guess.
...
> > Couldn't you store them as "150 160 155 170" an interpret the first in
> > each pair as the minimum and the second as the maximum?
>
> This could work for ranges because we know each range is made of two
> values, what about the case where we don't know how many values should
> be in each list element? For instance "10,15,18 12 13,10". No, I don't
> have a use case.
That's true. I wonder if it admits too much complexity, though. Oh
well.
...
> > I don't think it should be. As far as I know, macros, as you're using
> > them here at least, constitute part of the interface, so if they're not
> > declared public in the ARC case, then they shouldn't be recommended in
> > the manpages. Am I missing a loophole or something?
>
> I see your point and I tend to agree with you. But I don't quite
> understand why macros such as SCF_TMPL_VALIDATE_FLAG_CURRENT, SCF_TERR_*
> defined in scf_tmpl_validate_fmri(3SCF) but not in the interface table
> of the ARC case are a different case.
I suspect you'll have to amend the case. Liane will know better.
...
> I think there are two confusing terms. One is property group that is a
> configuration data and is defined in the xml tag <property_group> in the
> manifest. The other is the property group template pattern that is
> metadata for the property group and is defined under the xml tag
> <pg_pattern> in the manifest. We have a similar case for property
> (<propval> in the manifest) and property template pattern (<prop_pattern>).
> I am not sure how's the best way to differentiate them without using the
> word template.
As I think you figured out, I don't have a problem with the word
"template". It's the refernce to targets of property groups that is
confusing.
> > The scf_tmpl_pg_target() function will retrieve the target of the
> > property group template and place it in *out.
> >
> > would work.
> Agree, this works and may also answer my question above...
> I'll also change the phrase for scf_tmpl_pg_{name|type}().
...
> > That's easier to understand, though I think it would help to specify
> > that each separator is a single character.
>
> re-phrased to:
> "The scf_tmpl_prop_internal_seps() function will retrieve the list of
> internal separators as currently defined in the template. Each
> separator will be a single string character in a different element of
> out."
Good.
...
> I agree with you, I have changed 'instance FMRI' to 'service instance'.
> I am afraid this would also call to change the function name to
> scf_tmpl_validate_instance(3SCF) but I'll wait for consensus (and
> self-convincing) before making such a change.
Technically, yes, but I think the current name is understandable because
there are two ways to specify an instance: an scf_instance_t, and an
FMRI.
David
