On 10/ 4/10 01:48 PM, William Schumann wrote:
Ethan,
On 09/25/10 03:26 AM, Ethan Quach wrote:
...
Regarding the use of the table + template with prefabricated script
notion - you make a lot of good points. This is too far from being an
elegant, broadly useful solution. I would like to leave the notion of
this in the proposal as a suggestion, perhaps for a future enhancement.
Generally, table-driven solutions are still possible through
user-defined scripting.
5.3 - I really don't like the use of a comment as the marker to denote
inclusion time. Did you look into simply using a made up attribute
to the
<xi:include> element as our marker? In a quick test, I specified the
following in a real XML file:
<xi:include href='file:/etc/svc/profile/name_service.xml' foo='bar' />
ran it through 'xmllint --xinclude' and it resolved the xinclusion
seemingly ignoring the additional attribute. If this can actually work
this may be a better approach. It qualifies as well formed XML. It
does not interfere with the inherent Xinclude statement.
This seems a lot better than using comments.
And most
importantly, since its part of the XML, we can programmatically
process the XInclusions as we choose, using the python lxml library.
In looking at the lxml.etree.XInclude class, we can element-wise
resolve xincludes as we process a DOM, which means that we can
support a file with mix-n-matched Xinclude statements that the
user wants handled at the three various times. Thoughts?
The problem is that if the inclusion option is specified per xinclude
instance, there is no way to indicate that the profile itself is
static - i.e., copied locally into the installadm database for
previously stated reasons (section 5.3: protected, less 500 internal
server errors, etc.).
Isn't the main profile file itself always copied in? I hadn't realized
this
proposal was offering that as an option to the user.
Not what I was thinking - will state this explicitly in the proposal.
...
Also, instead of a comma separated
list, could we make it be multiple -c instead? This would make it
consistent with the -c option of add-manifest and set-criteria. In an
offline previous conversion with Frank a while back, he noted that we
should try to be consistent in that nature, among our commands.
OK. Does this also apply when more than one profile is specified? e.g.:
installadm add-sc -g -p p1.xml -p p2.xml
I would think so.
Unlike AI manifests, there can be an indefinite number of SC profiles.
Also, for profiles, scalability is a requirement. Hence, I think it
would be useful to relax that requirement so that shell wildcarding can
be used. For example, if there are many profiles n the current
directory, all having the .xml file extension, they can specified in
this way:
installadm add-sc -g -p *.xml
The shell will replace '*.xml' with the name of each file with the .xml
extension and entries will be made for each of those profiles.
If you wanted to do that then the command structure should not require
the -p at all; the manifests should be the objects of the command, not
arguments. That, though, would make this quite different from the rest
of the installadm command structure, so is it really needed? I am
somewhat unconvinced that the number of SC profiles to be operated on at
one time will greatly exceed those of AI manifests.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
