Amicus is an experimental core for the Friend Unifying Platform.

The main goals of the project are:

  Make the code more readable and maintainable with these rules of thumb:
  ‣ No source file longer than 1000 lines.
  ‣ No function longer than 100 lines.
  ‣ No indention deeper than 5.

  Improve integration with posix based environment.
  ‣ Use ordinary methods to build and install.
  ‣ (Optionally) use system users (authentication with PAM).
  ‣ Use available libraries and applications in favour of own
  ‣ Rely on the kernel for file caching and everything else best done by the
  ‣ Use posix standard for where to put all files.

  It has yet only been tested with Linux, and it may contain some Linux
  specific code. But the goal and is to have it run on at least *BSD and
  Solaris as well.

The main changes in regard to the FriendUP core are:

  ‣ Refactored the code and somewhat untangeled dependencies. The size of the
    codebase was significantly reduced. Most sources of compile time warnings
    are gone.

  ‣ The design around data structures phased out in favour of a more object
    oriented design.

  ‣ Try to be consequent troughout the codebase. For example always use
    (the arbituary value of) FILENAME_MAX for all temporary filenames on the
    stack istead of using other arbituary values. Always use snprintf() in
    favour of sprintf() then writing to buffers on the stack.

  ‣ Removed custom implementations in favor of standard C99. The many custom
    inline implementations of functions such as strlen(), strcmp() and
    strchr() are replaced with ordinary function calls to the standard
    functions. Custom data types (without clear intension of usage) are
    removed in favour of standard types, such as bool and uintptr_t. Also
    replaced usage of depricated functions with modern ones, such as
    nanosleep() instead of usleep().

  ‣ Unified library loading. All libraries and plugins are handled in the same
    way (with the same code).

  ‣ Rewrite of HTTP request handling. Make the requests abstract objects and
    hide all HTTP details. Try to send the response as soon as possible
    instead of buffering it. This opens up to using sendfile() without the
    need to make file streaming a special case for requests. This also opens
    up for API introspection and automatic help text generation. As well as a
    transparent way replace PHP code with C code function by function (instead
    of module by module) without even changing the API.

  ‣ Rewrite of file handling. An object oriented design which provides an
    abstract base class two implementations. Files on disk and files in
    memory. To make it easier to implement file system handlers where is
    also an API where the handler only need to know how to fetch and store
    whole files. The concept of a file is decoupled from the concept of a
    mounted file system (the latter is refered to as a volume in the source
    code, but that terminology is not exposed to the user as the intension
    is to keep all communication with the client identical to FiendUP).

  ‣ Open the SQL library only once for the connection pool. Since the
    library can handle multiple simultanious connects it doesn't need to be
    dynamically linked again for each connection.

  ‣ Depend on external packages instead bundling libwebsockets and minizip.

  ‣ Includes a module for authentication using PAM.

  ‣ Includes a module for handling SQLDrive DOS Driver. (A module written i C
    instead of the one written i PHP).

Most of FriendUP core internal APIs are broken, including all APIs for libraries and modules. But all web APIs should be completely compatible. At least that's the intension. The configuration files are also compatible.

Compatibility with PHP modules is currently maintained. But some loosely defined APIs might be broken in the future due to stricter definitions.

Amicus does not include any PHP, JS, HTML, CSS or such, just the C core. For it to actually do something usefull you also need everything but the core from the Friend Unifying Platform.

snisurset.netContact the author.