cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill de hOra (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-373) storage-conf.xml reformatting
Date Wed, 19 Aug 2009 20:55:14 GMT


Bill de hOra commented on CASSANDRA-373:

1. Wherever possible, lines should wrap at 75 chars.

is this not best done by reducing the comment noise? 

Also verbose comments tend to be annoying in practice operationally - hey get in the way of
the the actual elements  you need to set/read when you need to see/read them on a console
- tomcat is example offender and a system i'm tired of stripping comments from.

4. Path locations that conform to the FHS.

Not for us to mandate surely.

 * The tilde's at the beginning of the comment lines impair reading.  

* I don't like putting advice or good rules of thumb in the config - would we do this kind
of thing in the thrift? 

 * CommitLogSyncDelay : "in millis" but other elements have the InFoo quantity pattern. Inconsistent.

 * MemtableObjectCountInMillions: asking people to type in floats is error prone, why not

* CommitLogSync: doesn't document its legal values

* Thrift*: should be wrapped in an holding element. Because, and I'm guessing here, Thrift
will not remain the only, or even the default, transport/api.

* InitialToken: doesn't document what happens when empty

* Seed, ListenAddress, ThriftAddress: don't document whether they take Ipv6 addresses

> storage-conf.xml reformatting
> -----------------------------
>                 Key: CASSANDRA-373
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Eric Evans
>            Assignee: Eric Evans
>         Attachments: v1-0001-CASSANDRA-373-re-format-factor-conf-storage-conf.xml.txt,
> Our sample config (conf/storage-conf.xml) is the canonical source of configuration documentation.
As such readability should be a priority, and it should serve as the best possible basis for
> I propose the following:
> 1. Wherever possible, lines should wrap at 75 chars. The file will be edited post-installation
by operational personnel, who are often confined to standard 80 character terminals.
> 2. Indention of 2 spaces to make maximum use of horizontal real estate.
> 3. More distinctive multi-line comments.
> 4. Path locations that conform to the FHS.
> Patch to follow...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message