Proposal for Property/Response Files reference and value substitutions Draft 0.3 Weijia (John) Zhang Dell Inc

Background and Problem Statement Operating Systems and Application installers use various property files and response file for the installation. These files include java property files, unattend files, kickstart files, inf file, ini files, HPQ package.xml file, and response.xml files etc. In order to use these files natively, the SDD will include information regarding these files

Changes from v0.1 to 0.2 per discussion with Randy and Christine The Response file content will be a separate file. The content of the response file will not be encapsulated in the SDD file through the RawData type. If the value of a parameter is specified in both SDD and the external response file, the one in the SDD will take precedent. The LanguageEncode parameter is removed as it is already represented in CharEncode. Add Artifact type to the AdditionalFile Define types of “ResponseFile”

Changes from v0.2 to 0.3 per discussion with Randy and Christine Remove “ResponseFile” type and use the one in the Purpose field. Remove the original page 4. Move up the substitution tag to the primary file level Reword precedence wording

Start SDD Handler Package- Descriptor.xml Parse Package Descriptor Deployment- Descriptor.xml Parse Deployment Descriptor Get Paramters/Values Substitute Parameters/Value to the response file Check for response file? Invoke InstallationUnit Yes No Work flow of parameter/value substitution for the response file

- … InstallArtifact without a Response File

… InstallArtifact with a Response File Changes: Add ResponseFile type to the AdditionalFile Add substitutionType and substitutionNumber to the parameter element

ResponseFile type: Potentially three sub-types a) open and structured b) open and unstructured; c) closed format. substitutionType: a)byString: Replace a string in the response file with the value of that parameter as specified in the SDD b)byName: Replace the value of the named parameter in the response file with the value as specified in the SDD. SubstitutionNumber: Specify Number of substitutions. Default to “all” Explanation of Substitute attributes

Linking SDD with the Additional (External) files The linkage between the SDD and the property/response files can be done via the following The SDD pointing to the Property/Response file via AdditionalFile tag. The file location should follow the general URL format. The parameter and value of the response file can be specified in the Parameter tag of SDD. When SDD runtime processes the parameters for the AdditionalFile, it will override the strings or values in the AdditionalFile. The ResponseFile type is specified in the file purpose. The response file can be Open-and-Structured (like property file), Open and non-structured, and close format. The ParameterType contains substitutionTYpe and substitutionNumber. The substitutionType can be by string or ByName. ByString means a pattern search and replacement and ByName means finding the name of the a particular parameter and replace it with value specified in SDD.

Substitution Algorithm additionalFile = Get_AdditionalFile(); If (Get_additionalFile_purpose() == ResponseFile) { foreach( getParameters() ) { if (get_substitutionType() == byString) { replaceString(additionaFile, get_parameterName, get_parameterValue); } else if (get_substitutitionType() == byName) { setValue(additionalFile, get_parameterName, get_parameterValue); }

Other questions and considerations How to find the replaceable names and values in the template file (AdditionalFiles) and SDD. Do we need to support Regular expression? Store of inventory result(?) AdditionalFile naming conventions (Do we need to support localized filename?) Do we support remote AdditionalFile location by using an URL? Mapping the name and value can be done by using URL name and value pair. Some definition can be used. Is there a need for a Property/Response file type? Is there a need for Property/Response file version?