Frank Ludolph wrote: > Jack Schwartz wrote: >> On 06/08/09 14:37, Frank Ludolph wrote: >>> Jack Schwartz wrote: >>>> HI Sue and Frank. >>>> >>>> Susan Sohn wrote: >>>>> On 06/05/09 11:40, Jack Schwartz wrote: >>>>>> Hi Sue. >>>>>> >>>>>> On 06/05/09 09:07, Susan Sohn wrote: >>>>>>> Jack, >>>>>>> >>>>>>> On 06/03/09 18:13, Jack Schwartz wrote: >>>>>>>> Hi everyone. >>>>>>>> >>>>>>>> I have updated the Manifest Inter-File Organization Functional >>>>>>>> Specification per yesterday's meeting discussion. Changes deal >>>>>>>> with how default sysmap manifests are defined/handled. >>>>>>>> >>>>>>>> Link is here: >>>>>>>> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.4.pdf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> With regard to default sysmap manifests, it now states the >>>>>>>> following: >>>>>>>> >>>>>>>> - - - >>>>>>>> >>>>>>>> A service setup command designates one sysmap manifest to be a >>>>>>>> service's default sysmap manifest. A default sysmap manifest >>>>>>>> will ?match? all systems for which no Sysmap Manifest with >>>>>>>> explicit matching criteria exist, so a default sysmap manifest >>>>>>>> does not need to have criteria. Any criteria in a default >>>>>>>> sysmap manifest will be ignored. >>>>>>>> >>>>>>>> A (non-default) sysmap manifest must have criteria to be >>>>>>>> useful. Non-default sysmap manifests without criteria will be >>>>>>>> ignored. >>>>>>> >>>>>>> Why not just say that the default sysmap manifests will not have >>>>>>> criteria? That way, the user could replace the default manifest >>>>>>> by simply adding one without criteria and we wouldn't need a >>>>>>> special command. It also seems less ambiguous as the distinction >>>>>>> between a default and non-default sysmap manifest would be more >>>>>>> apparent. >>>>>> We discussed this at the Tuesday meeting. Originally, what you >>>>>> are suggesting is what I wanted: to have a clear distinction >>>>>> between default and non-default manifests. (I wanted to enforce >>>>>> this by schema.) But then I thought we all agreed that it would >>>>>> be simpler and more straightforward to designate any manifest >>>>>> (with or without criteria) as a default manifest. One can easily >>>>>> swap a manifest in and out as the default temporarily without >>>>>> having to edit or re-edit the manifest, change the service, or do >>>>>> anything painful. >>>>> >>>>> I can see advantages to both sides. It just seems to me like it >>>>> might be confusing for users to have the same manifest cause >>>>> different behavior, depending on how it is used. I'd suggest that >>>>> you ask for Frank's input on this one. >>>> As Ethan also pointed out, defining a default sysmap manifest as >>>> one without criteria means there can be only one file without >>>> criteria. How would we handle the case where someone plops a >>>> second criteria-less sysmap manifest onto the system? We would >>>> still need a way of saying one of those two files is the default >>>> manifest, so a command would still be needed. Alternatively, the >>>> default would be given a certain name, and a second file would >>>> overwrite the first; suppose the first file is desired again. It >>>> still sounds to me like having the ability to install any sysmap >>>> manifest (with or without criteria) as a default is preferred. >>>> >>>> >>> Note that if you have two criteria-less sysmap manifests, the one >>> designated as default will never be selected because all non-default >>> manifests are evaluated first and one with no criteria will always >>> be selected before taking the default. >>> >>> As a rule it would seem that only one criteria-less manifest can be >>> active at a time and that it must be the default. If a criteria-less >>> manifest is the default and another manifest is made the default the >>> original criteria-less default manifest would have to be deactivated. >> Yes, a single manifest would be installed as the default. When that >> manifest is installed, the previous one would be de-installed. >> > I didn't phrase it well. The point is that there shouldn't be an > active criteria-less manifest that isn't also the default, otherwise > it will be the defacto default.
That really depends. If we're choosing to say that "criteria-less" does not mean "default", then the algorithm to choose which one the default is obviously won't even be looking at criteria; it'd just be looking for the one marked default. -ethan > > Frank >>> >>>>>>>> - - - >>>>>>>> >>>>>>>> Here's how I see that this will affect at least the AI services >>>>>>>> and webserver teams: >>>>>>>> >>>>>>>> 1) Need a command or way of selecting a new default sysmap >>>>>>>> manifest. >>>>>>>> >>>>>>>> 2) Define that if there is only one sysmap manifest specified >>>>>>>> for a service, it is the default. >>>>>>>> 3) Define how the default file is provided (e.g. by the user, >>>>>>>> template, ???). If a template is not provided as part of AI, >>>>>>>> need to insure that a default sysmap manifest is provided by >>>>>>>> the user when the AI setup command is invoked. >>>>>>>> >>>>>>>> 4) Define warning message behavior (if any) if a sysmap >>>>>>>> manifest with criteria is specified as a default. (Maybe no >>>>>>>> message?) >>>>>>>> >>>>>>>> 5) Define what to do with the old default sysmap manifest, if a >>>>>>>> new sysmap manifest is installed as the default sysmap >>>>>>>> manifest. (Keep it around, trash it, ??? I suggest keeping it >>>>>>>> in case the user has modified it or created it.) >>>>>>>> >>>>>>>> 6) Define warning message behavior (if any) if a >>>>>>>> previously-default sysmap manifest with no criteria is now no >>>>>>>> longer a default. (I suggest no message.) >>>>>>>> >>>>>>>> 7) I don't suggest an explicit command for uninstalling a >>>>>>>> default sysmap manifest per se. Instead, I suggest that we >>>>>>>> impose that there will always be a default, by implicitly >>>>>>>> uninstalling the old default when installing a new one. >>>>>>>> >>>>>>>> 8) Need a way of listing all sysmap manifests, including the >>>>>>>> current default. >>>>>>>> >>>>>>>> Comments? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jack >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
