To more accurately summarize what needs to happen in terms of where the pieces
of the jigsaw fit in;

* A trigger is going to be (primarily) responsible for the data in a set of
mail folders to be turned into PFBs,

* We may also have some sort of interval based iteration to see what needs
updating, but the result of any findings would just be to issue a trigger,

* This "generator" (that is being triggered) can simply use administrative
credentials, and authorize itself as a target user (if appropriate). For
security, we MUST ensure;

  - The administrative credentials are read from a configuration file every
time it is needed, and discarded as soon as possible,

  - The codepath MUST NOT allow for any deriviation off of the path to
authorize itself as (including signal handling, and so forth),

Note that an administrator has implicit "a" rights only, and can actually not
lrsipwdexc without assigning itself such rights first.

* After the "generating" job is done, it is time to update the aggregated
data. It seems simplest to either do this immediately after "generating", but
why not make this a different job. We don't really care at first, but we may
want to consider structuring codebase design so that we allow for aggregation
to be a separate job in the future.

* For a /freebusy/trigger/ over HTTPS to be able to just insert a job and
issue 200 OK instantly, for a backend notify() to be able to just insert a
job, and for various other reasons, we'd like this freebusyd to be able to
use;

- a "remote" job queue (in the future), or
- an "external" job queue (local SQLite anyone?),
- or, alternatively, opens a socket for jobs to be inserted (while it
maintains the queue in memory).

  We could, at first, safely assume this socket does not require
authentication, and does not require TLS/SSL, and instead use a firewall to
authorize connections from certain systems (i.e. a localhost deployment
requires the connection be made over loopback).

* The aggregator is going to need to be responsible for Resources' calendars
to be published F/B information for, and it's likely to only ever reside on a
filesystem (or in SQL for distributed setups). For each resource collection,
the combined PFBs need to be negated into a "any resource in the collection
free" type of free/busy (see Resource Management[1]).

* If so inclined, this freebusyd should be made a codebase that is relatively
easily reusable should server-side akonadi take the stage. It suggests a
source code tree layout along the lines of src/lib/, src/daemon/,
src/akonadi/, if you'll humor the line of thought.

Kind regards,

Jeroen van Meeuwen