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