* Michael Shapiro <mws at zion.eng.sun.com> [2006-08-28 15:49]: > I've confirmed that fixing scf_entry_add_value() fixes the problem, insofar > as I can tell by executing experiments. Jonathan, is there some more subtle > issue inside the repository I should be aware of? I don't recall this > decision, but as I say above it makes no sense --
Umm, it's actually quite sensible, if you think about how to support multi-valued properties in the network name service implementations currently in use. Ordered responses are not generally supported by these protocols--forcing the scf_* interfaces to order responses means one or more tradeoffs in the network repository representation, which I was not prepared to make at the time. Tradeoffs that I worked through were: addition of an ordering column in each row (insertion becomes an ID renumbering series of operations), versus pickling multiple values into a single row (bounded by network repository maximum row length) or multiple rows (reduces bound, but reintroduces renumbering and chunk management). I'm happy to discuss which of these we pursue, but I would like this choice to be made before changing the behaviour. It doesn't look like the behaviour made it into the reference documentation (although it is in the architecture document), so the impact on current practice should be minimal. We can then actually document the ordered behaviour... > in particular it makes the use of multi-value network address > properties nearly useless. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
