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. Also, svccfg/svcprop/libscf would have to change too so that the set/sequence nature of a property could specified/observed. Nico --
