Nicolas Williams wrote: > On Wed, Jun 11, 2008 at 10:55:53AM +0100, Alan Maguire wrote: > >> David Bustos wrote: >> >>> So what is your take on Stephen's network repository issue? I wonder if >>> we could add a piece of metadata to properties which specify whether >>> they're ordered or unordered. By default they'd be ordered, but if an >>> application doesn't care then it can make them unordered, which would >>> free svc.configd to avoid emulating order in an unordered backend. Or >>> maybe the ordering should be a flag on the retrieval interface. Or >>> maybe the current retrieval interfaces should be designated "ordered", >>> and we can add separate unordered retrieval interfaces. If we wanted to >>> do this, we could probably put it off actual unordered properties until >>> we have a network backend, and make any interface changes as >>> opportunities arise. >>> >>> >>> >> Nice summary of the options. Defaulting to ordered >> storage/retrieval would be my preference here, with >> possible future changes based on explicit requirements >> for unordered value support. I'm not quite sure what >> constraints the network repository requirements would >> impose - what do you think Stephen? >> > > What would happen on upgrade? Which order would be assumed for existing > multi-valued props? Or would those be flagged as unordered? I > recommend the latter. > > The thing is, we cannot determine anything about user intent regarding ordering of properties that exist prior to upgrade to the order-preserving repository format (well we can I suppose - consumers should not expect any particular ordering). In practice, what will happen is that existing property values will share a value_order of 0, so when these are retrieved, the value_order will not order things in any definitive way. However, if/when such properties are later set, the order of setting will respect the order of properties added via scf_entry_add_value(). The benefit of this change is more for services/properties added after it is made - these will be able to take advantage of definitive ordering of values.
> Also, svccfg/svcprop/libscf would have to change too so that the > set/sequence nature of a property could specified/observed. > > No need as far as I can see - testing indicates these all just work, since scf_entry_add_value() and the backend do the right thing. I think what we?d need to do is ensure that manpages document the ordering behaviour. Alan
