Hi everyone.
I am fixing bug
4325 Implement data types for A/I criteria on server side
which is to allow the criteria manifest to list MAC addresses with or
without colons, and IP addresses with or without periods. (This is
because currently, both addresses are allowed in the manifest only
without any punctuation.)
This fix is intended to be temporary, with the "real" fix going in as
6620 Multiple XML parsers are used in the slim_install gate
For this bug, I plan on validating the data, and then stripping off the
punctuation from the addresses as part of the validation process. This
way, code changes are minimal to the rest of AI, which already expects
punctuation-less addresses.
There are a few ways I could fix this bug:
1) Check against schema patterns with and without the dots or colons.
For IP addresses, this is just fine, because there is only one address
to check. For MAC addresses, a range must be accommodated. This means
that combinations of starting and/or ending MAC addresses need to be
validated. There are 9 combinations since start and end can both be one
of ("None", with colon, without colon)). Since the (None x None)
combination isn't allowed, that reduces to 8. The main problem comes
when two addresses are specified and one is buggy. The buggy one will
be interpreted as a string and will thus errantly pass validation. A
more minor issue is that the pattern is long and cannot be divided into
multiple lines, and so it is messy. Python code is used only to strip
the punctuation, and so is small (~ 50 lines including function header
and comments).
2) Don't use the schema, and just treat these addresses like strings.
Do validation in python code. This keeps the schema looking cleaner,
and the python code isn't that long (under 100 lines commented, for both
types of addresses). The problem here is that a range entry with two
strings must be accommodated, compromising other criteria which use lists.
3) Allow the manifest to list only one address if a range is not
desired, and two if a range is desired; and use the schema. This gets
past the problem of buggy strings slipping through validation, and cuts
down on the number of combinations to list in the schema (one for a
single entry, one for a range, when the <choice> option is used.)
Drawbacks: the minor issue of the long pattern will remain. Another is
that users will see a change. Not sure if there are other implications
for other parts of AI.
My vote is (3) if it is feasible, but would like others with more
knowledge of AI to chime in. Is (3) the best solution to others who
know AI well?
Thanks,
Jack
