Sarah Jelinek wrote: > Ethan Quach wrote: >> >> >> Dave Miner wrote: >>> Ethan Quach wrote: >>>> >>>> >>>> Dave Miner wrote: >>>>> Ethan Quach wrote: >>>>>> >>>>>> Notes and decisions from previous meetings have been posted >>>>>> to the project page here: >>>>>> >>>>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/DerivedProfilesProblemStatment/ >>>>>> >>>>>> >>>>> >>>>> Regarding note 2, Scope: It seems like we actually would support >>>>> both, based on the proposed separation of the derivation process >>>>> into a separate SMF service; by supplying an alternate instance or >>>>> implementation of that service, a user could do complete, >>>>> from-scratch derivation if that was preferred for their situation. >>>>> In that case, this is really more about what the default, provided >>>>> capability will require of the user, right? >>>>> >>>> >>>> Yes, that is correct. We are describing here what AI by >>>> default provides for this functionality. >>>> Supplying an alternate instance or implementation, while >>>> possible, isn't something I was planning on explicitly stating >>>> in the functional spec. >>>> >>> >>> Why not? >> >> I was thinking about supportability. Would it be something >> we officially support? But if that doesn't matter in the context >> of a functional spec, then I can certainly state it. > > I don't think we should support full derivation. We may allow for > deriving of every field, but the actual derivation of the manifest from > top to bottom seems like we could introduce possible compatibility > issues. I believe the intent of not allowing this scenario made it > easier for us to ensure manifest/schema compatibility for validation. >
The manifest format will be an interface, and in fact a public one of some sort, so I don't see what issues it creates that we wouldn't already have. What do you think they would be? Dave
