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.
Thanks,
Jack
>
> Dave
>
