On 05/11/09 14:43, Dave Miner wrote:
> 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.
OK. Got it.
A new installer version can remain compatible with an old manifest in
many cases (for example when there are additions which can be defaulted
if they are missing from a manifest). In the case of a new installer
version with an incompatible change (e.g. changes in the semantics of a
previously used item), we would want to gracefully abort. We need to
handle both cases.
So, here's how (3) can be reworded:
3) AI manifests need to be forward and backward compatible between builds.
- Manifests of different versions than the automated installer must
work whenever possible.
- A given version of the automated installer must be able to
recognize a manifest with which it is not compatible and gracefully fail.
Thanks,
Jack
>
> Dave
>
