Request for comments: Sorting fields in signature generation

[Johannes Ernst]

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