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. 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. > >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. Nico --
