Short term:
  + formalise and improve configuration file:
    one for server
    one for client

  + rework diff-ing of metadata, eventually use modifiers;
    in progress (2004.07.31), by passing custom attribute match list
    to Entry.compare
    probably finished (2004.08.01); can specify attributes to check or
    attributes to skip from default list;

  + password query from cfv/cfvadmin;
    should use termios/fcntl for sys.stdin;
    solved by using getpass

  + fix sqlite getEntries;
    only after implementing properly getEntries at sql level, with
    search options
    fixed, at least is at postgres level	

  + add/store get item names from file

  + fix filtering on areas by username in server
    maybe some ACL system
    done in server.conf

Medium term (before beta release):
  - implement test suite - HOW???
  + reorganize the encoding of data payload;
      done by using driver-specific binary encoding: for postgresql
      this is bytes and psycopg.Binary() wrapper on write, on read is
      auto-decoded; for sqlite, using sqlite.encode()/sqlite.decode()

  - finish user manual (quickstart maybe?);
  - make a plan for: 
      - virtual items: could be area type or prefix? prefix ugly, area
      type most logical; current area is filesystem;
	- 2005 May 19: area is no good, we want all files of a server in
	one area, including virtuals; this means that it must be a
	per-item flag, like source: filesystem, command output, etc.
	- in this case, it means that source: filesystem is for
	non-virtuals and source: command output is for virtuals; in
	the latter case, the `name' attribute is the command line, it
	will be broken down at space and executed as is - so no shell
	escapes/variables/etc.
	- a problem exists with virtuals naming; if the virtual's name
	is the command line, it is difficult to `cat', `stat', `diff'
	and so on of virtuals; it would be better to have the virtuals
	named with simple names; in this case, is the item.name
	attribute still unique? yes, but in virtual case, it should be
	named like v:name, not /dir/file. This creates a redundancy,
	in the fact that the type (virtual or file) is already
	determined from the `source' field, but it allows a clear
	demarcation of virtual _names_ and file _names_
	- maybe it would be better to allow a site-specific naming,
	i.e. let the local admin determine how to name the virtuals,
	using a _real_ file name, and in this case the retrieve will
	use that file for retrieval; for example, it could be
	/virtual/df for the `df virtual` or /virtual/fdisk for fdisk
	-l; I think this is best
	- virtual entries should be diff'ed based only on
	filecontents (and exit code ?), not other attributes; they
	behave almost as regular files with no metadata. the size and
	checksum will be stored, though.
	- in conclusion, virtual have real file names, they have the
	following contents: command output, and the following
	metadata: exit code; the command output is composed of:
	stdout, written into file contents, and stderr, which for now
	we don't have a separate field and is combined with stdout;
	for exit code, we have exitcode

      - deletion: items are put in a suspended state, from where no
      errors are signaled if they don't exist, however new versions
      are stored if they appear on the filesystem; the deleted state
      is signalled by a new attribute to an Entry, `state`, which can
      take the values of 'A' (alive), 'D' (deleted or dead :), 'F'
      (frozen, this takes care of forced offline items and
      virtuals). Freshly registered items will have an empty Entry
      with a 'B' (born) state.

      only A state have complete information; D, F, and B have not
      info except for filename

      what about deleted virtual items? They will be handled by the F
      state.

      - rename: dont really know... maybe by delete + new item? 
      ideally, a link of some kind would need to be stored in the new
      revision to the old (latest) revision.
      would only apply to filesystem items, or to virtual also?

Long term (post 1.0):
  - analyze implementing non-sql repository;
  - think about delta storage;
  + add 'export' command which makes a tar of
    a given revision (or range of revisions?); then we
    can measure with bakonf
  - unify output options?
  - unify search/filter options to different subcommands
        Based on repo.getEntries
        Global search options:
          * start in all areas (--all-areas) or current area (default)
          * filters are AND only
          * retrieve only one entry per item (default) or multiple (--all-revs)

        Our tests:
        + -r, --revno:  by revision number(s); this means:
                <,>,!=,= N
        * --comitter:   by commiter regex match
        + --logmsg:     by logmsg regex match
        * --rev-ctime:  by revno ctime
        - --rev-uid/gid/user/group
        + --all-areas or only "cfv -a" area

        From find, * planned, - not planned, + implemented
        - --amin
        - --anewer
        - --atime
        - --cmin
        - --cnewer
        - --ctime
        + --empty       File is empty and is either a regular file or a directory.
        - --false
        ? --fstype
        + --gid         File's numeric group ID is n.
        + --group       File belongs to group gname (numeric group ID NOT allowed, unlike find).
        + --ilname      Like -lname, but the match is case insensitive.
        + --iname       Like -name, but the match is case insensitive.
        + --inum        File has inode number n.
        + --ipath       Like -path, but the match is case insensitive.
        + --iregex      Like -regex, but the match is case insensitive.
        + --links       File has n links.
        + --lname       File is a symbolic link whose contents match shell pattern pattern.
        - --mmin
        - --mtime
        + --name        Base of file name (the path with the leading directories removed) matches shell pattern pattern.
        - --newer
        + --nouser      No user corresponded to file's numeric user ID at store time.
        + --nogroup     No group corresponded to file's numeric group ID at store time.
        + --path        File name matches shell pattern pattern.
        + --perm        File's permission bits check.
        + --regex       File name matches regular expression pattern. This is a search on the file name.
        + --size        File  uses n units  of  space.
        - --true
        + --type        File is of type: b,c,d,p,f,l,s
        + --uid         File's numeric user ID is n.
        - --used
        + --user        File is owned by user uname (numeric user ID allowed, unlike find).
        ? --xtype       The same as -type unless for symbolic links checks the type of the target.
