Jack Schwartz wrote: > Hi Dave. > > On 05/11/09 13:05, Dave Miner wrote: >> Jack Schwartz wrote: >>> Hi Dave. >>> >>> Thanks for your comments. >>> >>> On 05/11/09 12:08, Dave Miner wrote: >>>> Jack Schwartz wrote: >>>>> Hi everyone. >>>>> >>>>> Minutes from this meeting are posted at: >>>>> http://www.opensolaris.org/os/project/caiman/auto_install/AI_mtg/Minutes/XML_parser_rework_minutes_090507.txt >>>>> >>>>> >>>>> >>>> I don't understand what's meant by the "carries a lot of >>>> information" portion of the below. Carrying a lot of information >>>> isn't inherently a problem, so what's the real problem being hinted at? >>>> >>>>> 2) Current AI manifests are not easy to use. >>>>> - fragmented, could be better organized, carries a lot of >>>>> information. >>> Carrying lots of information isn't a problem if that information is >>> well organized. Combined with the file being fragmented and not >>> organized as well as it could, carrying a lot of information makes >>> the file harder to read. >>> >>> I'll drop the "carries a lot of information" part. >>>>> - We decided that changing from XML is out of scope and off the >>>>> table. >>>>> >>>> Additionally, I'd suggest some alteration of the below: >>>> >>>>> 3) AI manifests need to be forward and backward compatible between >>>>> builds. >>>>> - Old manifest to work on new build >>>>> - Have old build recognize new manifests and fail in a >>>>> user-friendly way >>>> I think it would be more general to say that "A given version of the >>>> automated installer must be able to recognize and gracefully fail >>>> when presented with a manifest with which it is not compatible." >>>> The specific old/new statements above seem a little too restrictive >>>> and would potentially lead to solutions which are insufficiently >>>> flexible for the product's future evolution. >>> Well, I could take your wording (and I'd like to), but... >>> >>> Reading between the lines here, are you suggesting that we need to >>> support that a manifest of a given version works with both up-revved >>> and down-revved installers? >>> >> No, I wasn't suggesting that. The specific wording was chosen in an >> attempt to avoid that implication. > Phew! >>> If that's the case then we should make that as part of the problem >>> statement as it's more complete. (This is assuming that now is the >>> time to completely define the problem.) The other way implies that >>> there may be manifest versions which won't work with a given >>> installer version. This way says all manifest versions will work >>> with any installer version. >>> >>> What's your opinion on this? >>> >> There is no requirement that everything work with everything. Do you >> think such is even possible here? > It would be hard if not impossible. >> My opinion is that we desire to maintain compatibility of manifests >> moving forward, but should assume there will be an incompatible change >> required at some point and that the installer should fail gracefully >> when presented with one. That requires that the installer be able to >> differentiate between compatible and incompatible manifests. > OK. That's what I thought I captured earlier. > > So back to your original statement: how do you see what I wrote earlier > as too restrictive? What solutions would it lead to which are > insufficiently flexible for the product's future evolution? I want to > be sure I understand where you're coming from. >
In your original terminology, I don't see that you capture the possibility that new builds may wish to not maintain compatibility with old manifests. Dave
