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. If we don't want to support full derivation, why would we support an alternate service? For test and development maybe? sarah **** > > > -ethan > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
