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.