Hello, On Jan 5, 2011, at 6:32 PM, Viktor TARASOV wrote: > On 05.01.2011 17:22, Martin Paljak wrote: >> On Jan 5, 2011, at 5:22 PM, webmas...@opensc-project.org wrote: >>> Log Message: >>> ----------- >>> pkcs15-tool: new 'bind-to-aid' argument ... >> Why not --aid ? > > Mainly because of pkcs15-init, where there are already application-id, > application-name arguments related to the DATA object. > I would like to make considerable difference between them and this new > argument. > For all tools its name is the same. > > If you think that it's excessive, we can change it for the shorter variant.
Options to pkcs15-init can get long and cryptic and sometimes feel ad-hoc (at least to me), especially if you do less common things. For example, try using --label to personalize a card with a SO pin (with a label other than "Security Officer PIN") and with a label for the card (other than "OpenSC Card"). Not really intuitive, if not to say that buggy (does not really DWIM). Maybe the data object related options could be re-named and/or re-organised to make better sense in the required context? Coming from the lower level, the AID is quite fundamental for the rest of the parameters to make sense (think of the layering of reader -> card -> application on card -> object under application). IMO the logic is comparable to --reader being shorter and more casual than --connect-to-reader. Ideally command line tools should be usable (for those who know what they want to do and comprehend the domain) with little or even no help from the manual and also with terminals and shells that don't support auto-completion (meaningful short options for most often used commands are good, whereas less used options should not eat up the valuable short option space). Here a fine balance between evolution, conscious design and backwards-compatibility should be found. Also, doc/tools/pkcs15-*.xml should be updated. It would be nice if somebody kept an eye on such things and remind others (like me) to not forget docs with code commits. I will have to document --reader [num | name | atr] behavior... Cheers, Martin -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
