Field separators, again
brad at danga.com
Tue Jun 7 16:45:44 PDT 2005
On Wed, 8 Jun 2005, Paul Crowley wrote:
> The nice thing about this is that we can also use it for our token
> format, replacing the rather ugly and unreadable
> with the far more debuggable
> (using mode:id_res to do the job of assert_identity in the other format)
I don't get that part. How is this content-type issue related to the
what-are-we-signing issue? Please don't merge them as one issue. Don't
lock us into one serialization format.
> Brad suggests that servers can provide more than one format, on the
> assumption that servers are smart but consumers are dumb, so servers
> should provide whatever consumers will find most convenient. One thing
> some consumers might prefer, for example, would be XML. I think that's
> overkill for now; everyone should be able to parse the format here with
> hardly any code.
And it might be ZERO code if their environment treats XML as a first class
type, as more and more do.
As for server-side "overkill", you don't need XML libraries on the server
to generate XML... you just print out:
I think that's easy for any server to do, provided the XML fans in the
audience can tell us what schema they'd like.
Then they say:
Then we leave it to consumers to decide which they want to parse.
> In Python, for example, you can do it with
> dict([(lambda x, y: (x, y.rstrip()))(*l.split(':',1)) for l in f])
> What do other poeple think?
I think that obfuscated one-liners don't help win arguments in favor of
simplicity of parsing. :-)
In the end, I don't care much about this issue, but I don't want to fight
over it for long.... which is why I favor the consumer-decides approach.
More information about the yadis