On 07/19/10 09:34 PM, Dave Miner wrote:
On 07/19/10 07:35 AM, William Schumann wrote:
On 07/14/10 09:47 PM, Dave Miner wrote:
On 07/14/10 10:13 AM, William Schumann wrote:
...
Is dynamic inclusion at install time preferable to static? Should we
provide the option of either?
I would think that dynamic (or "late") binding is closer to users'
expectations than static (or "early") binding of inclusions because
it's more consistent with overall system behavior these days. I'm not
sure I see a case for both...
It is true that the dynamic binding is how Jumpstart works. Otherwise,
I can only partially agree; e.g., the entire AI server is presently
based on static definitions.
The case for a static binding option: once the SC manifest is verified
and locked in:
- almost no possibility of the "500 internal server error + reason" on
the AI client during dynamic processing due to SC manifests
- the sysadmin can rely upon the manifest not being inadvertently
changed, e.g.:
--- any subsequent changes that break an inclusion framework (XInclude)
would not affect the static manifest
--- an XInclude inclusion framework could be deleted - either
intentionally or accidentally - without affecting the manifest
- remote inclusions using HTTP would not be affected by network outages
between the AI server and the included manifest at the instant the file
is requested
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
