Unfocused ramblings on modules, hooks and related issues
--------------------------------------------------------

Richard Jones, 28th December 2001.

Mount points
------------

Conceptually  it would be nice to  be able to mount multiple different
filesystem  personalities onto a single   tree. For example, we  might
have /  being a normal anonymous FTP  site (ie. the "RO" personality),
but on this we mount:

  /incoming
    - Magical incoming directory: each client gets their own
      incoming directory so they cannot see files uploaded by
      other clients. This is generated by means of a special
      Net::FTPServer::Incoming personality, possibly similar
      to the current InMem personality.
  /whatsnew
    - Magical directory containing recently uploaded files.
      This is generated by a personality linked to server
      administration.

This seems  at  first easy enough to    do. Unfortunately FTP  doesn't
really support this, because users are required to log in exactly once
at the beginning of the session. How would multiple personalities work
if,  say, the  / personality  allowed only  anonymous access, but  the
/incoming   personality    required  a  valid    username  & password? 
Additionally  each  personality might  want to  chroot  to a different
directory.  It looks like this isn't possible, at least not easily.

Parsing pathnames
-----------------

Apache  modules     see   the  full  pathname     of    each file: eg.
"/path/to/file". Net::FTPServer  knows the current directory  and sees
just "file". This difference in design is implied by the difference in
the HTTP  & FTP protocols.   Namely that  HTTP is  stateless  (clients
always  supply  a full path  on  each request), whereas FTP  is (very)
stateful.

So   this  naturally raises   the question:  why    do we  expose  the
statefulness of FTP in the  backend? In other  words,  why not have  a
backend  which sees stateless  paths. The translation between stateful
FTP   and stateless backend is  done  in the main lib/Net/FTPServer.pm
code, like this:

CLIENT REQUEST			WHAT BACKEND SEES
  USER foo
  PASS bar                        LOGIN foo, bar
  CWD /incoming
  LIST				  LIST /incoming
  STOR foo.txt			  OPEN /incoming/foo.txt; WRITE; CLOSE

(Of course the backend is not totally  stateless, because the user can
only log in with  one set of  credentials, unlike HTTP  where separate
credentials are given on each request).

Mount points are slightly simpler to do with a stateless backend. Also
a stateless   backend does not   need to be done in   an OO style, but
rather as a simple set of entry points (call  them hooks -- see below)
which can be considered an advantage.

What is a hook?
---------------

Modular server -- is it desirable?
----------------------------------
