ideas.txt

Here's just some ideas for features for the future.  (Yes, as I freely
admit, I'm one of the worst perpetrators of feeping creaturism for
proftpd.)

mod_tls:
  + allow TLSCipherSuites on a per-<Directory>/.ftpaccess basis, and thus
    can be used to trigger renegotiations for tighter restrictions on
    directory contents.

  + add TLSAllow/TLSDeny (or somesuch) for <Limit> context, for limiting
    certain FTP commands only for use by FTPS sessions that employ certain
    cipher suites.

Stackable FSIO

  pr_register_fs() needs a flags parameter, to register whether an fs_t is
  an FSIO_FILTER or an FSIO_ANCHOR (can a module possibly function as both?
  Perhaps...but it will have to choose which mode to use).  "anchor" is
  just an easy/short way of saying "source/sink".

  Only some of the I/O routines (e.g. read()/write()) will cascade through the
  stacked module list (pr_fh_t will point to a list of fs_t's, rather than
  to a single fs_t).  Or, better: some will start with the anchor, then
  progress (bottom up) through the filters (e.g. open(), read()); others
  will start with the filters (top down) and end with the anchor (e.g.
  write(), close()).  The list of fs_t's is assigned when a filehandle is
  opened.  The code looking through the fs map will need to be changed.
  Registration order will be important.  The output (len) from filters
  will be input into the FSIO call.  Any error output should stop the
  cascading through the stack (or maybe it shouldn't...what if a fs doesn't
  support a given operation, but the fs's above/below it do?)

    Function:    Direction:

    stat         anchor -> head
    lstat        anchor -> head
    open         anchor -> head
    creat        anchor -> head
    read         anchor -> head
    lseek        anchor -> head
    readlink     anchor -> head
    opendir      anchor -> head
    readdir      anchor -> head
    mkdir        anchor -> head

    rename       head -> anchor
    unlink       head -> anchor
    close        head -> anchor
    write        head -> anchor
    link         head -> anchor
    symlink      head -> anchor
    truncate     head -> anchor
    chmod        head -> anchor
    chown        head -> anchor
    chroot       head -> anchor
    chdir        head -> anchor
    closedir     head -> anchor
    rmdir        head -> anchor

 With the new mapping, it will be possible for an fh to have the same fs
 multiple times (e.g. fs1 is registered for /, fs2 is registered for /tmp);
 however, the same fs cannot be registered _to the same mount point_ multiple
 times.

 The storage of registered fs_t's, and their mount points, will be...fun.
 Order of registration is important (not _inverse_ order).  The opening of
 a filehandle will necessary mean a search through the registration list,
 finding all fs_t's whose mount point touches on the opened file's path.
 Hmmm...will it be by order of fs_t registration, or by scope of mount
 point?  Probably by mount point first, general (e.g. '/') to specific;
 in the case of matching mount points, then in the order of registration.

mod_sql_sybase
  + mod_sql backend for Sybase

mod_search
  + implements a SITE SEARCH command, for using nftw(3), globs and regexs
    for scanning a site for a given filename pattern

mod_svn
  + implements source code control for files uploaded/downloaded from
    server using Subversion

mod_vscan
  + scan for viruses on incoming and outgoing files
    (Note: there is a mod_clamav that is a step in this direction)

mod_magic
  + use libmagic for identifying a given file type (a la file(1))

mod_auth_ntlm
  + authenticating against a Windows box

mod_slp/mod_zeroconf/mod_bonjour
  + see www.openslp.org, www.zeroconf.org

Language Bindings:

  + mod_perl
  + mod_python
  + mod_php

mod_quotatab
  + shared quota limits, a.k.a quota profiles

    This would help solve the question of default quotas, and allow the
    same limit quota to be easily applied to multiple entities, each
    of which would have its own individual tally.

  + directory size limits

    This would address the question of "How can I set a limit on the
    size of /path/to/dir?".  In effect, it requires implementing tree-based
    quotas, quotas based on location rather than ownership.  Much
    complexity in how location-based tallies would interact with
    ownership-based tallies.

EBCDIC support