On Fri, Apr 05, 2013 at 06:47:10AM -0400, Jiri Zupka wrote:
> >
> > I think ":" would work, but it looks strange because the final ":" has a
> > different meaning from the ":" in the middle.
> >
> > >
> > > 3) Exchange '>' to '::'
> > > little more performance expensive
> >
> > Why exactly "::" would have any performance problem?
>
> only comparison of char and multiple char and more one if many times.
It doesn't like one extra string comparison will will affect the
performance of the parser at all. If we were worried about those tiny
optimizations we wouldn't be writing the parser in Python. :-)
>
> >
> >
> > > only host_os::linux2 should work
> > > host_os::linux1: var = 2 could work but
> > > host_os::linux1: work but
> > > var1 = 2
> > >
> > > 4) Exchange '>' to '-'
> > >
> > > only host_os-linux2 should work
> > > host_os-linux1: var = 2 could work but not good visible
> >
> > What "not good visible" means?
>
> If you have lots of
>
> host_os-guest1.virt_os-linux.sdff-aaaaa.
>
> Then it could be hard to see in first sight in logs. could be hidden in text.
> And as you wrote before looks like part of name.
>
> >
> > > host_os-linux1:
> > > var1 = 2
> > >
> > > Which of this version do you prefer most or do you prefer some different
> > > version?
> >
> > So, the main problem here seems to be how to make the "<condition>:"
> > blocks look good and intuitive.
> >
> > The answer is: I don't know! I need to think about it a little.
> > Currently I see two main possible approaches:
> >
> > * The ones you proposed above (Use something else than "=").
> > I believe any of ":", "::" or "-" look better than ">". I think I
> > would choose "::". ":" is confusing (see my comment above), "-"
> > doesn't look like an "operator", but just part of the variant name.
> > * Require some kind of delimiter when "=" is involved. e.g.:
> > only [host_os=linux2]
> > [host_os=linux2]: var = 2
> > [host_os=linux2]:
> > var = 2
> > [host_os == "linux2"]: var = 2
> >
> > I would love to hear suggestions from others as well. Paolo?
>
> I like this version. It could be easy and fast for parsing. And good visible.
> only [host_os=linux2]
> [host_os=linux2]: var = 2
> [host_os=linux2]:
> var = 2
>
> disadvantage: This breaks today syntax. There could be choice
> for named variant and filtering with name in config have to be
>
> only [host_os=linux2]
>
> for unnamed it could stay as it for keep compatibility.
It should stay compatible, yes.
>
> only linux2
> but could be replaced by
> only [linux2]
Exactly. Just like quotes are recommended but optional when assigning
strings, The [] delimiter could be recommended but optional on variant
name/conditions.
I like that approach because we could slowly change the parser to accept
more complex expressions inside [].
Also: I would like to make sure all the following formats work:
[host_os=linux2]
[host_os = linux2]
[host_os="linux2"]
[host_os = "linux2"]
In other words: instead of making the semantics based on
substring-matching in th config-dictionary names (the long
"foo.bar.baz.etc" strings), it is now a human-readable expression that
describes a subset of variants/dictionaries.
>
>
> only [host_os=linux2.guest_os]
> or
> only linux2.guest_os
I don't know if you did that on purpose, but the above case is
interesting because it contains two components ("linux2.guest_os") in
the variant value.
I mean, this is easy to make work:
variants guest_os:
- Linux
- Windows
only [guest_os=Linux]
Now, what about this:
variants guest_os:
- Fedora
variants: # this one could be "variants fedora_version:"
- 15
- 16
- 17
- RHEL
variants: # this one could be "variants rhel_version:"
- 5
- 6
In this case, how can somebody say "I want only Fedora 15"?
Some alternatives I see:
(I am including all that came to my mind, including ones that I
find wrong or ugly)
only Fedora.15 # already works
only [guest_os=Fedora.15] # looks wrong to me
only [guest_os = "Fedora" and fedora_version = "15"] # I like this one, but
requires a more complex parser
only [guest_os = "Fedora" && fedora_version = "15"] # Like above, but for
people who like C operators
only [guest_os=Fedora]..[fedora_version=15] # This follows the
existing rules about "..", but looks weird
only [guest_os=Fedora].15 # makes sense, follows
the existing rules about ".", but looks weird
only [guest_os=Fedora..fedora_version=15] # looks really wrong to
me
I have two questions:
* Which formats are going to be accepted by the parser?
* From the formats that work, which format are we going to recommend
to users?
>
>
> host_os=linux2.guest_os: this will be interpreted like variable
> assignation.
> [host_os=linux2.guest_os]: condition.
>
> It could be little confusing for users..
I believe in this case the blame is on anybody who write a line like the
one above in a real config file. Even without the named-variants support
the above line looks ambiguous and ugly to me because of the final ":"
and the lack of quotes.
We could even change the parser to print a warning in case people use
special characters (like space, "[", "]", ":", "=", ",", etc) inside
variable values without using quotes.
>
> This version is quite overkill from my point of view.
> [host_os == "linux2"]: var = 2
>
> I tried to ask person which never see this syntax how they understand
> host_os::linux2 and [host_os=linux2]
> and they choosed [host_os=linux2] as more intuitive understandable.
Makes sense to me.
--
Eduardo
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
