Re: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting.
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting.
On 01/29/2010 07:53 AM, Pavel Zuna wrote: John Dennis wrote: 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. A File Command class validates by assuring the file is readable, it's normalize reads the contents. Then it calls the matching Str command class with the data it read. The Str class validate and normalizes the string data unaware it originated from a file. On the server side it never sees the File Command parameter, only Str parameter. Think of the File Command as a temporary command parameter which generates the resulting Str parameter. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting.
John Dennis wrote: On 01/29/2010 07:53 AM, Pavel Zuna wrote: John Dennis wrote: 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. A File Command class validates by assuring the file is readable, it's normalize reads the contents. Then it calls the matching Str command class with the data it read. The Str class validate and normalizes the string data unaware it originated from a file. On the server side it never sees the File Command parameter, only Str parameter. Think of the File Command as a temporary command parameter which generates the resulting Str parameter. I think we've been through this before. It would definitely be nice, but it would require a redesign and rewrite of the parameter framework and that's probably not worth it at this point. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting.
On Wed, 2010-01-27 at 17:53 +0100, Pavel Zuna wrote: cli.prompt_interactively now loads files before validating the parameter value. It also populates a list of already loaded files, so that cli.load_files knows when a parameter already contains the file contents. Fix #557163 Pavel ack. This looks reasonable to me, but I'd really like you to add some tests for this, especially testing that it works correctly for a command with multiple File params. Rob and John, do you see any problems with this approach? Does this address the needs of the cert plugins? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting.
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 jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
