Request for comments: Sorting fields in signature generation
Johannes Ernst
jernst+openid.net at netmesh.us
Wed Sep 27 18:11:42 UTC 2006
On Sep 27, 2006, at 9:55, Barry Ferg wrote:
> Johannes, if as you say "many people do this kind of thing in many
> circumstances", why limit their ability to do so in this circumstance?
I'm simply acknowledging that many people do this.
Of course, a substantially larger number of people doesn't do this.
For example, there is a reason why most people prefer
interface Foo {
public String getName();
}
over
interface Foo {
public String [] getName();
}
just to be safe in case some instance of Foo might have two names
some day. (There are some who always do the second.)
> This proposal doesn't _force_ anyone to us multiple parameters
> with the same name. I'm in favour of keeping the specification
> flexible by not imposing unnecessary restrictions on future
> extensions to the protocol.
>
> For that matter, isn't having implementation issues in certain
> restrictive development environments drive the specification kind
> of like the tail wagging the dog?
I'm not making that argument (although it shouldn't be ignored
either). The argument I'm making is that an equally important problem
occurs on a higher level, which is harder to solve than writing a few
additional pack or unpack routines.
> On 26-Sep-06, at 4:44 PM, Johannes Ernst wrote:
>
>> On Sep 26, 2006, at 16:13, Josh Hoyt wrote:
>>> I think the real topic of this discussion is whether or not multiple
>>> parameters with the same name should be allowed by the
>>> specification.
>>
>> I'd support the motion of not doing that.
>>
>> I realize many people do this kind of thing in many circumstances,
>> but in my experience, it always turns out to be more trouble than
>> it's worth.
Johannes Ernst
NetMesh Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20060927/9d3d988a/attachment-0002.gif>
-------------- next part --------------
http://netmesh.info/jernst
More information about the specs
mailing list