-*- Indented-Text -*-

* Logging in to the AFP server

  Because AFP is session-oriented, each request coming from
  the kernel must be handled in a session corresponding to the uid in
  the credentials.

  If no mapping has been set up, a default "guest" session is used, if
  a guest user and password has been entered. If the AFP server
  supports anonymous authentication, that is used.

  How should the user authentication be performed?

  + a fixed database with (AFP server, UNIX name) -> (AFP name, password)
    mappings.
    - Bad. Passwords should never be kept anywhere in the clear. (But
      AFP servers presumably keep them, how else could the RandNum
      exchange authentication be implemented?)

  + Some means of telling a running afpmount your password for the AFP
    server in question.  
    
    - RPC call. Too complicated? How to distinguish between multiple
      afpmounts running?

    - An "emulated" file in the root directory? *Yes* The afplogin program
      writes to that file, afpmount notices the write, and saves the
      user name and password for later use. THIS IS HOW IT IS DONE.

* Uid and gid mapping

  Several alternatives:

    - A fixed database (text file), read at startup, containing
      mappings.

    - Map only logged-in or users, other uids and gids are mapped to
      some improbable number.

    - Assume if identically named logins/users and groups exist in
      both UNIX and the AFP server, the are equivalent.  CURRENTLY IT
      IS DONE IN THIS WAY.

* Mount whole server or volumes individually

  + Currently afpmount mounts itself once, representing the whole of the
    AFP server. The server's volumes show up as directories under
    the file system root (mount point).

    - Pro: simpler?

    - Pro: one umount is sufficient to unmount the AFP server.

    - Con: if statfs is to return some space usage values, it must do
      several FPGetVolParms calls and sum up the values.
  
    - Con: File IDs should be uniquified based on volume id? Is this
      necessary or doesn't the NFS client (kernel) also look at the
      fattr.fsid when identifying files?

  + Perhaps afpmount should mount the volumes under the root.

    - Pro: statfs needs to do one FPGetVolParms, and the result is
      directly usable.

    - Pro: File IDs need to be uniquified for .resource and
      .finderinfo only. 

    - Con: Several umounts are necessary to unmount the AFP server.
      The umounts of the volumes must be done first, then the root.
