Syntax (was syntax.txt)
corey at axcelerant.com
corey at axcelerant.com
Mon Jun 25 00:55:04 PDT 2001
And upon Monday of June 25, the illustrious Jason Gurtz spake thusly...
> > I don't think that the config, build and install tags should be
> > manditory.
> Here is my proposal for a template profile:
> <name />
> <version />
> I submit that <pre>, <build>, and <post> are all optional by default; only
> <package>, <name>, and <version> will be mandatory to a profile.
I'm in total agreement with the above proposal - I like it and
certainly can not yet see any issues with it. If I were to have
any sort of minor suggestion, it would be to rename the pre and
post tags to 'prebuild' and 'postbuild', as I believe XML tag names
should be explicitly described. XML is a meta-data mark up language -
used to *describe your data*. This for one thing helps weed out
possible future ambiguities.
> The next issue is deciding on initial tags that actually do somthing.
> Here is my submittal of what is neccesary:
I'm thinking of another possible approach, see below.
> <param /> if there is more than one of these, they are applied top to bottom
> in order as arguments to the 'commanding' tag.
> <dir /> the directory where the 'commanding tag' is run.
> <src /> source file/directory
> <dest /> destination file/directory
Rather than defining tags and their requirments on a per
command basis, we make a more broad and general 'command'
<command id='1' name='mv' src='/bin'>
Equates to '/bin/mv -f /foo /bar'
The 'id' parameters are required: for the 'command' tag so
that the code logic knows the order in which the commands
shall be executed - and for the 'opt' tag, so that the code
logic knows the exact order in which the options should be
provided. The 'name' and 'value' tags in the 'opt' container
element should be required, but of course are not always
necessary, so can be left blank.
We use the parser to construct the exact form of the command,
and then simply execute it - rather than defining translation
code for each of the "allowable" commands for which we've
strictly facilitated for in the DTD. This will enable the same
exact code logic to perform the execution of *any* command,
plus allows the packagers the freedom of running arbitrary
commands that may be required for their specific package, but
not defined for in the DTD. Thirdly, this does not require
us to make provision for every command that may ever need
to be ran in the DTD.
The cons of this approach though is that we lose the ability to
enforce required parameters for commands in the DTD - for instance,
there is no longer a 'src' tag that is flagged as required in the DTD
for the 'link' command. Thus, a packager can fail to include this in
his template profile, and the parser won't catch it - instead this
will create an exception in the code logic during execution. It is also
possible the packager misspell 'ln', for example, in the command tag's
'name' param, causing another exception at runtime - or it now becomes
possible for packagers to include commands that are not on the target
system's environment. ( however, this can be solved through dependencies
and other means, I have a few decent ideas for this possibility ).
Freedom and Flexibility, losing Control and Structure?
Or Control and Structure, losing Freedom and Flexibilty?
What do you guys think? I tend to favor flexibility.
> I know this is a lot but how 'bout some comments =)
Now how was *that* for a lot? (c8=
Keep the ideas/suggestions and comments rollin' guys!
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss