* Architecture
** Sessions
*** Session creation

When creating a session =three actions= are taken:
- The session's directory is getting watched, unless its already watched
- A timer-based validator function is being created
- The session object is added to the list of unvalidated sessions

The steps taken above is done in order to handle a couple of different scenarios:
- The underlying =dtach= session is never created, the validator will recognize this and never insert the session into the database
- The session is correctly created and is running when the validator is called, it will update the state from =unknown= to =active= and insert the object into the database
- The session is finished quickly before the validator is being run, it will trigger a session directory event, this will update the session and insert it into the database, at the same time it is removed from the list of =unvalidated= sessions which will cause the =validator= to not do anything

The logic described mean that the Emacs that creates the session is responsible for validating the session. Only when a session has been validated, or become inactive, it will be added to the database. When it is added to the database it will cause other =Emacsen= to read from the database and then become aware of existence the session.

*** Session initialization

The initialization of  =sessions= when =detached= is loaded is performed in the following steps:
- All known sessions are read from the database
- The directory where the database resides are being watched in order to detect updates made to the database
- A hash-table is created where all keys are session ids, and the values are the status, which is initialized to =uninitialized=
- For all sessions that are accessible, which is either local sessions or remote sessions with an active connection
  + The hash-table is updated to =initialized=
  + The sessions =initialized-emacsen= property is updated with the process id of the current Emacs
  + If the session is registered as =active= the session is updated if it has transitioned to =inactive=, otherwise its session directory is being watched
  + If the session is missing, =e.g.= it has been deleted from the computer, the session is removed from the database

***  Session transition

The =detached= sessions are read from the persistent =detached.db= file when the package is loaded. All =Emacsen= that loads =detached= are reading and writing to the same database file, that allows the sessions to be shared among Emacsen.

To avoid all Emacsen from sending a notification when a session becomes inactive the responsibility is determined dynamically. All Emacsen, where detached is loaded, registers their process in a file named =detached-emacsen=. Initialization of sessions are done on a session basis
