Nicolas Williams wrote: > On Wed, Jun 11, 2008 at 08:38:48PM +0100, Alan Maguire wrote: > > Let's take this in reverse order: > > >>> 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. >> > > Perhaps I misunderstood. I thought you were adding a notion of ordered > vs. unordered. But perhaps you're merely imposing order always on all > props added from the time this feature is available. > > Right (to the second part) - the suggestion is to always impose order. > The former implies UI and API changes (though not necessarily > backwards-incompatible) by which users/programs could specify whether > they want a property's values to be ordered. > > The latter implies no UI changes nor API changes. > > It seems so, though it?d be good to ensure these changes don?t step on any of the network repository requirements. >>> 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. >> > > This leads me to believe that you're simply changing semantics rather > than extending the SMF data model (see above). That's fine with me. > > Great! Thanks for following up - I think you?ve captured the idea behind these proposed changes really clearly here.
Alan
