Keith Mitchell wrote: > > > Frank Ludolph wrote: >> Ethan Quach wrote: >>> >>> >>> 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. >>> >>> >> No, default is what is selected when everything else has been tried >> and failed. If there is a criteria-less manifest that is not the >> default, it will always be selected before the default. >> >> Frank > It took my brain a few minutes to absorb this conversation. If there > happens to be a manifest in the system, and it has no criteria > attached, then the AI engine would immediately upon examining it find > a match. Which means any active manifest in the system with no > criteria would end up being chosen the moment it is examined.
But the AI engine doesn't have access to the list of manifests on the server. This processing is done on the server side, and a single manifest is passed to the AI client from the server. -ethan > > > This is separate from the behavior that takes place after the AI > engine looks at all active manifests and can't find a match. At that > point, the AI engine falls back to the "default" manifest. > > From that perspective, a manifest with no criteria that is defined as > "non-default" in some fashion is an error condition, that should be > dis-allowed, or at least, warn the user about. > > -Keith >>>>>> >>>>>>>>>>> - - - >>>>>>>>>>> >>>>>>>>>>> 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 >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
