Features

. Audit

	- add user auditing, i.e. save all commands that were run

	- save to a local file (distributed DB would probably be an
	  overkill)

. Cluster documentation

	- one of the more recent features is graph capability
	  (graphviz) which is a very good step in terms of cluster
	  documentation; need to extend that with some textual
	  cluster description and perhaps history and such

	- everybody likes reports (and in particular your boss)

	- this feature needs very careful consideration

Misc

. Create a web page

	- there's already space at crmsh.nongnu.org

	- preferred to be based on asciidoc or similar

Code improvements

These are some thoughts on how to improve maintainability and
make crmsh nicer. Mostly for people looking at the code, the
users shouldn't notice much (or any) difference.

Everybody's invited to comment and make further suggestions, in
particular experienced pythonistas.

. Parser

	- the current parser is just awful

	- the parser should be implemented in one of the existing
	  python parsing libraries/tools, such as PLY or pyparsing
	  (need to investigate which would be the easiest to apply
	  for the crmsh language)

	- proper parser should allow easier updates and easier
	  language extension (currently, crmsh doesn't support
	  some date rule constructs)

	- make sure that the new parser is not significantly slower
	  from the existing!

. Syntax highlighting

	- syntax highlighting is done before producing output, which
	  is basically wrong and makes code convoluted; it further
	  makes extra processing more difficult

	- use a python library (pygments seems to be the best
	  candidate); that should also allow other output formats
	  (not only terminal)

	- how to extend pygments to understand a new language? it'd
	  be good to be able to get this _without_ pushing the parser
	  upstream (that would take _long_ to propagate to
	  distributions)

. Language class

	- the crmsh language is packed just as a list of lists of
	  lists or thereabouts, which is not very convenient (in
	  particular for debugging); it actually used to be a dict,
	  then dicts wouldn't do as they don't guarantee order and I
	  didn't know at the time about ordered dictionaries

	- a class to capture the language should help

. Configuration edit is complex

	- at the time it didn't seem like anything less would do, but
	  it's worth revising

. XML production is ugly

	- due in part to preserving all XML ids (which may not be
	  necessary, but makes comparing XMLs for equality easier)

	- some kind of production rules set and a general XML machine
	  would be preferable

. CibFactory is huge

	- this is a single central CIB class, it'd be good to have it
	  split into several smaller classes (how?)

. The element create/update procedure is complex

	- not sure how to improve this

. Bad namespace separation

	- xmlutil and utils are just a loose collection of functions,
	  need to be organized better (get rid of 'from xyz import *')

. Add more comments

	- in particular describe how CibObjectSet, CibObject, and
	  CibFactory work together (that's the core of the configure
	  level)
