On Thu, Jul 08, 2010 at 05:59:13PM -0700, Brock Pytlik wrote: > I could ask the same question about the mode and path of out file > actions. Why do we separate them into two attributes when theres a > well known convention (the output of ls -l) which provides that > information in a single string. The answer for the file action, and > for the signature action, is that they're two orthogonal (or nearly > orthogonal) bits of information that would have to be split apart by > the consumer to use.
This is a bogus comparison. The output of ls -l isn't an interface, nor is it designed to be machine parseable. The mode attribute for files is defined by the system call interface, which presents the path and mode as separate arguments. Instead of trying to compare this to an unrelated part of the system, I'd consider the benefits and drawbacks particular to the solutions to this problem. > To me, the most compelling reason for two attributes, and the reason > that I'm going with two separate attributes is that the places where > I use the information they provide is located in two separate > places. I would need to take the single long string and parse it to > find the information I was looking for (rsa vs dsa or sha256 vs > sha512). Since there's no harm in storing the information in two > separate attributes, and it makes life easier, and in my opinion > clearer to the user, I think that's what I'll do. Bill has given a compelling counterargument: not all combinations make sense together. Instead of trying to parse the string, you can use it as a key into a table of supported algorithms. You just check if the string maps to something you know, and if so, you can have that map to a more useful binary data structure. There are other ways to do this too; OID -> codepoint was another example. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
