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.
Defining that the lack of criteria to distinguish a manifest as being a
valid "default" manifest would again rely on the content of the manifest
to indicate which is the default. I would much rather it be declarative
from the service's point of view.
In addition, tying "default" as being "the manifest with no criteria"
has other hidden implications.
- there can only be one manifest with no criteria.
- you cannot add a manifest with no criteria without making it
the default. (you may end up unintentionally overwriting the
what the default is without even realizing it)
- you cannot arbitrarily assign any other manifest (even ones
with criteria) as being the default.
-ethan
>
> 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
>>>
>>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
