http://github.com/udoprog/python-adc
I am basically finished writing the parser for the ADC grammar, and have a couple of questions/pointers I would wish to highlight.
Please note the following definitions from the ADC spec's:
Code: Select all
message_body ::= (b_message_header | cih_message_header | de_message_header | f_message_header | u_message_header | message_header)
(separator positional_parameter)* (separator named_parameter)*
positional_parameter ::= parameter_value
named_parameter ::= parameter_name parameter_value?
parameter_name ::= simple_alpha simple_alphanum
parameter_value ::= escaped_letter+
escaped_letter ::= [^ \#x0a] | escape 's' | escape 'n' | escape escape
A backwards compatible solution would be to change the definition of positional_parameter to:
Code: Select all
positional_parameter ::= ^parameter_name parameter_value
A more graceful solution would be to prefix each argument in order to specify the type (as example):
Code: Select all
positional_parameter ::= 'P' parameter_value
named_parameter ::= 'N' parameter_name parameter_value?
Code: Select all
encoded_cid ::= base32_character+
My suggestion would be to specify that a base32 string must be padded correctly, and the grammar be modified to support this;
Code: Select all
base32_padding ::= '='
base32_string ::= base32_character+ base32_padding*
encoded_cid ::= base32_string
...
to sum things up
- Named vs Positional parameters are too disambiguous to be parsed and validated in a formal (context-unaware) manner.
- Base 32 encoded strings are represented in a manner which prevents a parser from decoding them early, which in turn complicates the client implementation and decoding process.
- Why use base32 encoding to begin with when basically all known hashing tools to man by default represents hashes in base16?