--- On Fri, 1/9/09, Dejan Muhamedagic <deja...@fastmail.fm> wrote:
> > >2. Shorter specification of boolean variables
> >
> > Seems more cosmetic to me but have no reason to oppose.
> > Again strongly support *both* syntaxes.
> >
> > "not globally-unique" : NOK
> >
> > "!globally-unique" : OK, preferred over above
>
> Well, these are the same, some people of course do prefer
> '!' over 'not', but I still believe that most of the
> users are not programmers, so I assumed that they'd
> appreciate 'not' rather than C syntax.
>
> > "not-globally-unique" : OK
>
> This is an interesting proposition, but probably hard and
> error prone to do right.
Actually, I'm really less "unfavorable" to the "NOT" negatable keyword than
what I previously wrote. I initially had the impression that an attribute
keyword like "globally-unique" with multiple (and opposite) interpretations
depending on the presence of other keywords like "not", to have the potential
of being more ambiguous, and more complex to implement than multiple,
switch-behaviouring keywords with opposite meanings like "globally-unique" and
"not-globally-unique", if only because not *all* attribute keywords are
negatable, and because it clearly appears like a move away the
"verb-parameters-modifiers" command syntax we were originally introduced to.
As much as the decision to implement a "not" keyword or opposite attribute
keywords like "globally-unique" and "not-globally-unique" can ultimately be
considered as arbitrary, the key factor for it to not get in the way in every
day operations is general, overall consistency.
> > > 3. New "prefer" statement/clause for
> > > location preference ...
> > >group g1 global-ip web-server prefer node1
... and new modifier !
> > >group g1 global-ip web-server prefer node1
> >
> > Disagree with the one-statement.
> > Ambiguous. Represents an unspecified language construct.
> > Creates a name exception to handle the nature of this
> > language construct.
Which I maintain in regard of the original command line syntax but will be glad
to take this back if the intent is a command line syntax overhaul.
Let me suggest a command which does the same thing with a -100 score:
AVOID
> > How do you parse, what rules used to parse:
> > group g1 global-ip prefer prefer node1
>
> The prefer keyword would of course be reserved. Too bad for
> people naming nodes "prefer" ;-)
Guess you've undertaken a full command line overhaul for consistency. :-)
> > >new:
> > >colocate apache-group ms-drbd0:Master # inf is implied
> > >separate apache-group ms-drbd0:Slave # -inf is implied
> >
> > Unfortunately, ambiguous.
>
> The first one should mean: keep the two together,
Conceptually, I imagine this more like "a fellow always entering the same pub",
rather than "keeping this fellow and the pub *together*." ...
> the second: separate the resources. How exactly ambiguous?
and "preventing a fellow from entering some specific pub", rather than "keeping
the fellow and the pub *separate*" ...
Then, you can't apply "colocate" to a single entity, it applies to at least
several entitites that share the same location. "This fellow and his buddy
*colocate* this pub."
Same applies to "separate".
Makes sense ?
> > Also, "colocate" and "separate" not the best words
> Any suggestions? I'm all ears :)
I think what you mean with "colocate" is actually LOCATE, with the following
possible synonyms: HOST, CONFINE, PLACE, KEEP, BOUND, BIND, RESTRICT ...
And for "separate", you probably should better use: DENY, BAR, BLOCK, BAN,
PROHIBIT, FORBID ...
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
