Jack Schwartz wrote: > On 07/31/09 06:31, Dave Miner wrote: >> >>>> >>>>>> >>>>>> The solution in use case 3 tries to infer format based on the >>>>>> attributes specified, and misses existing and future options. For >>>>>> example, it's possible to install SVR4 packages from an http URL, >>>>>> and IPS will have an on-disk format in the future. I strongly >>>>>> recommend making declaration of package type explicit, if that's >>>>>> necessary, or have it automatically resolved by your solution >>>>>> based on a recognition of the location's format (which may be >>>>>> relatively simple). >>>>> Good point. Better not to assume a certain format or location type >>>>> for different kinds of packages. I think being explicit about the >>>>> type of package is better than resolving it automatically for the >>>>> following reasons: >>>>> - It makes the package type explicit in the manifest, with no extra >>>>> effort on the user's part. (Instead of "package" elements, we can >>>>> have "IPS", "legacy" and "DU" elements to call out the specific >>>>> types.) >>>>> - It is more maintainable, since if some new format of a package is >>>>> introduced, the installers won't have to be updated to recognize them. >>>>> >>>>> Additionally, it is simpler for us to implement at the outset. >>>> >>>> I would not use "package" elements. Perhaps call it a >>>> "driver_bundle" or something of the sort with an additional "type" >>>> attribute. This avoids further overloading the package term, and >>>> limits the amount of change to the schema required for additional >>>> types, should any future ones be needed. >>> I changed "package" elements to "IPS", "legacy" and "DU" elements. >> >> That would still leave the problem of needing a schema update to add >> additional types, though, wouldn't it? I think it would be preferable >> to not need that. >> > Either way there would need to be a schema update if we add additional > types, but it is true that the change would be less.
I would have expected that we could leave the types as unspecified strings and validate them in the consumer based on what it implements, rather than making them explicit in the schema. > Looking at this with fresh eyes this morning, what I like more about > your approach is that it is more understandable to the user. > > So I'll change the example to: > <add_drivers> > <bundle type="IPS", name="SUNWraiddev", > location="http://myrepo";, noinstall/> > <bundle type="legacy" name="SUNWtata,SUNWtata2", > location="/media/usbstick/tatadir"/> > <bundle type="DU", name="*", > location="/media/du_volume"/> > </add_drivers> > Please use "SVR4" rather than "legacy", though, as it's precise. Dave
