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

[Pavel Zuna]

John Dennis wrote:
> 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.
I think our parameter classes follow a different logic. They don't provide any 
functionality (except for calling validation/normalization routines) and are 
pretty much separated from the rest of the ipalib code. They *describe* the type 
of value a command expects to receive on the command line (or in a field in the 
webUI). In other words the parameter classes define syntax of what a command 
expects as parameters, but they don't say anything about semantics.

This is why the File parameter extends the Str class - the command expects a 
string. Maybe we should rename it to Filename.

> 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.
I think there are two distinct cases for typical command line programs I know:
1) File is specified as an argument/option or contents are loaded from stdin.
2) String data are entered as an argument/option or loaded from a file specified 
with another argument/option.

Both of them are used by sed and are doable with what we have. We don't have 
mutual exclusion for parameters, but it's easy to make one parameter override 
another one.

> 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.
The problem here is that validate/normalize can only be used on final values 
passed to commands. Both validate and normalize are called on the client and 
then again on the server. Files need to be loaded on the client, so you can't do 
it in a method that is shared.

> Thoughts?
> 

Pavel