[Freeipa-devel] [PATCH] Fix File parameter validation when prompting.

[John Dennis]

I've been thinking about this a bit more. I wonder if part of the 
inelegance is due to the fact we're trying to shoehorn two distinct 
concepts into one item when a proper relationship does not exist.

It does not seem logical that a file is a subclass of a string which is 
how this is set up now. Files simply do not derive from strings, they 
are two entirely distinct concepts.

Consider any typical command line program you're familiar with. You 
might pass string data as an argument or it might be read from stdin. 
But if you want that command to read from a file you have to pass it a 
different argument specifying the filename to open.

Take the case of sed for example. If you pass a script on the command 
line you use the -e arg, however, if you want to pass the script as a 
file you use the -f arg. They aren't the same at the point of 
invocation, internally the program maps one to the other.

Maybe that's why the proposed mechanism is awkward, we're trying to 
conflate one concept with another. Perhaps there should be distinct 
arguments available for the user to the use, one arg passes a string, a 
different arg passes a filename. The filename parameter opens the file, 
reads the content and then assigns the value to the appropriate keyword 
parameter. For the file arg you would have:

kw[param.alias] = value

instead of:

kw[param.name] = value

where param.alias is the name of the "destination" parameter associated 
with an alternative arg for supplying the same value.

In this scheme the you don't need to keep state, you don't need to 
special case any code, you can use the existing normalize and validate 
mechanisms.

Thoughts?

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/