Ethan Quach wrote: > > > 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 Apologies, that was a "vocab" error. I meant the AI server, not engine.
-Keith > >> >> >> 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
