Hi everyone.
On Tuesday at the meeting we decided:
- For mac and IP addresses...
- single values will be represented as a single value in the schema
(as opposed to a list with "None" and a value)
- a range of values will remain represented by a min and max value
- The punctuation-less variants will not be supported in the schema.
Thanks,
Jack
On 03/23/09 17:06, Jack Schwartz wrote:
> 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
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
