monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: A Two-Fold Proposal: On Formats And Front-Ends


From: Larry Hastings
Subject: Re: [Monotone-devel] Re: A Two-Fold Proposal: On Formats And Front-Ends
Date: Fri, 07 Oct 2005 14:56:08 -0700
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)


Graydon Hoare wrote:
We have to use *some* level of custom-notation because almost no other text notations normalize whitespace. Hashing imposes unique requirements.
I agree with your second statement, but not your first, unless you consider "normalizing the whitespace of an existing format" to be "some level of custom-notation".  Using XML/ASN.1/JSON and mandating an exact approach to formatting whitespace would have met monotone's requirements for reproducability and hashing.

Really, though, as long as your formatter produces consistent output, and that format is replicable by other people when important, that would work just as well.  It's valid, if inconvenient, to define the standard for "normalized" whitespace as "what the formatter in monotone does".


Graydon Hoare wrote:
basic_io was designed to be *relatively tolerable* for humans to read as well as machines.
Wheras Nathaniel J. Smith wrote:
The point of the automate split is, of course, so we can make the question "what format is best for humans?" and the question "what format is best for computers?" into different questions...
I'm with Nathaniel here, as I view those are conflicting goals.  As per my original proposal, I'd make the internal format convenient for programs to digest, and the front-end would convert between that format and something far more pleasing for humans to gaze upon.  Trying to serve both audiences with a single format had simply never occured to me, so I didn't recognize basic_io as being a dual-purposed solution when I saw it.

But that's all neither here nor there.  I have my answers.  There is a standardized data interchange format, basic_io, which will be used for all new business in internal data formats.  Public opinion is ambivalent regarding a split between the front-end and back-end; that part of my proposal was generally ignored in favor of the data format kerfuffle.  If I or someone else engineered such a split, I don't get warm fuzzy feelings that it would be accepted into official monotone releases.  Far more likely to make it in would be a re-engineered "stdio" mapping the breadth of monotone's command-line to basic_io stanzas (both in and out).

Cheers,


larry

reply via email to

[Prev in Thread] Current Thread [Next in Thread]