incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Appending "\n" and pretty printing output from the command line using curl (with a smidge of python)
Date Fri, 22 Aug 2008 15:57:44 GMT
On Fri, Aug 22, 2008 at 04:36:08PM +0200, Jan Lehnardt wrote:
> Thing is that CouchDB is talking HTTP to curl (or any other HTTP client) and
> not through POSIX interfaces with the OS and other programs.

This point is mute as curl is an application designed for a POSIX environment,
therefor its IO handling is designed for POSIX standards, therefor it doesn't
matter the input is coming from, only how the client expects to be able to
handle it.

But in any case, using curl like this is misdirection. We haven't built CouchDB
to be user agent specific and there are many more POSIX aware clients out there.

> So maybe curl should add a newline there to be POSIX compliant.

This would be awful and certainly not curl's mandate.

Principal of least surprise, etc.

> But I can see curl saying "I don't touch the payload" for a good reason, too.


> I don't really know what's practical now, but I don't think your argumentation
> is tight.

Can you point out any flaws in my argument other than the above which I think I
have refuted reasonably well.

The summary of my argument is as follows:

 * POSIX defines text files are being terminated by newline characters
 * POSIX aware software, including a very large subset of potential CouchDB
   user agents, expect that text files are terminated by newline characters
 * CouchDB does not currently terminate text files with newline characters and
   this has already proved troublesom in a minor fashion but could easily cause
   larger problems for unknown use cases.
 * Patching CouchDB to terminate text files with newline characters does not
   have any negative consequences pointed out so far.

Even if this was some hazy idea of best practice and not a standardised
procedure, we're dealing with a situation that only has upsides and no known
down sides. Combine that with the triviality of the patch involved and I really
can't see the case for rejecting this change.

> Maybe we can bring that before the resident ASF HTTP experts?

Sounds reasonable.

Noah Slater,

View raw message