Field separators, again
ken.horn at clara.co.uk
Wed Jun 8 03:22:47 PDT 2005
Paul Crowley wrote:
> Nathan D. Bowen wrote:
>> But instead of colons, why not use = as the separator? Then, as a
>> bonus, we can describe it in terms of its similarity to "Windows INI
>> format" or the "Java Properties format".
> Sounds good to me. Note that Java is also happy with colons though.
+1 on '=' if using text
>> "dh_public" in place of "dh.gy" (not all Diffie-Hellman
>> documentation uses the name 'gy')
> I'd prefer that the server use a different name than the client for
> its public part. Apart from that, I'm agnostic.
+1 on something other than dh.gy, more like dh_public, but don't care --
>> "digest_type" in place of "auth_type",
> Definitely not. What if the next revision uses UMAC?
what does auth mean? Authentication? Authorisation? Auth of what/who? To
whom? I prefer digest, but maybe that's because I don't really know the
difference between a digest and a MAC. How about "hash_type", cos to me,
they're all just fancy hash algorithms.
>> "encryption" in place of "enc" (enc looks like 'encoding' to me),
>> "encrypted_secret" in place of "enc_secret"
> Brad explicitly shortened these.
+1 on lengthening them, better explicit than implicit as the pytho's
say. Are we trying to save bytes in urls? thought we had loads of room.
>> If we opt out of the question of which single format to use for
>> responses, I shudder to think about the question "Why won't you add
>> my favorite format, too? After all, I see a format-selection step
>> right there in the protocol..."
> I also fear that. But it will be hard to add formats after the
> initial revision. If the consumer can't parse any of the formats in
> the initial revision, it won't be able to talk to old servers. If it
> can, there's no real point in asking for a newer format. My
> preference is still for just one format, but Brad has more experience
> than me here.
>> XML data is almost self-documenting. As long as we don't restrict
>> ourselves to simple name/value pairs, XML gives us the opportunity to
>> make the response format significantly more declarative and
> Personally, introducing the full complexity of XML gives me The Fear,
> but I'll leave that to others to debate.
If we are putting content in the requests/responses rather than using
pure URLs (my preference), then +1 on XML. It doesn't need to be complex
-- all I ask is that we use a namespace for the elements, and tolerate
tokens from other namespaces / unexpected elements/attrs (let's avoid
XSD due to its issues with back/forwards compat). This at least handles
encodings explicitly (UTF-8 please).
More information about the yadis