[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: <auth> parameter field names?
>My co-worker, Donald Eastlake, and I have been discussing <auth> fields we
>need to create for our own use and in the process we got into a discussion
>of <auth> field structure.
>
>Donald is a fan of named parameters (so you know which one is missing when
>you omit one). I can see the value of that, but still tend to think in
>terms of position-dependent semantics. What does the group think?
>
Carl,
I have to agree with Donald and I am speaking from experience right now. I
built some applications about a year ago which used position-dependent
semantics. Things have changed and I am now changing to a named format.
Here is some of my reasoning:
1) Things will change, what happens if one of your positions becomes
obsolete, you now carry it around for compatibility or create a new format.
2) Accessing things by name is some much easier and clearer than by position.
3) If good names are used it's fairly self-documenting.
4) It's order independent so implementers have some freedom.
5) It's easily extensible by adding a new name/value pair.
6) The parser is not difficult to write or very expensive to execute.
In point of fact, I'm using an encoding similar to what is used in the
query string of a URL for the stuff I'm doing. An example encoding would
look like name1=value1&name2=value2&name3=value3... You can even provide
for embedding special/binary characters using %XX (XX=hex value) notation.
You can also support multi-valued parameters if so needed.
So, my vote is for named parameters.
regards,
Jeff Parrett (starman@llnl.gov)
The stars are the limit!
References: