On Mon, Aug 28, 2006 at 02:20:49PM -0700, Michael Shapiro wrote: > > On Sun, Aug 27, 2006 at 01:55:33PM -0700, Alan Maguire wrote: > > > quick question about multivalued properties that are order-dependent > > > (in this case the property represents an option to a daemon that can > > > appear multiple times on the commandline). > > > > > > given that smf does not guarantee order being preserved for property > > > values, is the right thing to do to use a single astring value and a > > > separator > > > between each value in the string? > > > > Yes, that's exactly what you should do. > > > > Dave > > In terms of the command-line options thing that may be the right thing to > do but I think the more general case is entirely broken. We *should* > support order-dependent properties, otherwise typed multi-valued properties > are completely useless for a large category of problems.
I agree. > The only reason it doesn't work is a stupid bug in scf_entry_add_value() > wherein the code (to make its own life easier) adds new things to the > head of a linked list to avoid keeping a tail pointer. Actually, the interface wasn't derived from the implementation here. It has long been part of the design that all collections be unordered to "reduce the network repository requirements dramatically". I didn't make this decision, and don't know if the rationale still holds. I do know that it isn't just a bug in libscf. > As a result, > every multi-valued property ends up in the exact reverse order in which > items were added. I was planning on fixing this and updating the docs. That addresses the libscf half. You also need to verify that the repository format and protocol are designed to preserve ordering. Dave
