[Cweb-developer] Repository versioning and journeling

[Bryan T. <br...@th...>]

All ,

I was just thinking about how to reuse the workflow request journeling
mechansims
that Guy and I developed last year.  It occurred to me that we could be
journeling
all requests as a repostiory behavior, not only for workflow concerns.  This
gives us
one mechanism for restoring history, analyzing DOS attackes, etc.  We can
also
resurrect the resource versioning mechanism that I did originally and expose
access
to version histories as a service aspect for any resource.

   a. Migrate workflow request, error, log mechanisms into the core
      repository to provide optional journeling for all requests.  The
      journel entry should include the request headers, should
      optionally include various information about the HTTP
      Connection, especially the source IP, etc. for use not only in
      being able to playback the journel to re-create a repository
      state but also in analyzing DOS attacks.  Use the journel
      IDENTITY column to assign a unique local name to resources
      created during POST requests (unless overriden by
      Local-Name-Hint).  This will make it possible to replay the
      journel without breaking any depending external URIs.

   b. Add optional support for snapshot based version history to the
      representation table.  Consider whether this is the primary
      representation table or a secondary (and possible a set of
      secondary) representation tables specifically for version
      histories.  Note that XML diff algorithms could be used here,
      but we are already getting most of the benefit of from the
      request journel that if people use XPointer and PUT to make
      changes in resource state.

   c. Entries in both the version history and journel replay
      mechanisms can be sunset based on coherent repository state
      snapshots (as an optional admin task) since the repository can
      always be replayed from either the zero state or any other known
      state using the journel.  If the version history mechansism is
      used to restore the state of a resource, then it must be done
      using another PUT (walking in forward time only) otherwise the
      repository state can no longer be used for journel playback
      restoration.  That is: always make corrections through the HTTP
      interface, whether correcting by re-establishing the state of a
      resource from the version history or by re-establishing the
      state of the repository by playback from a known historical
      state.  Provide a mechanism to mark resources and requests that
      should not be re-created during playback so that the journel can
      be annotated such as to not re-create a journeled DOS attack
      during playback.

   d. Playback can encounter stale authentication tokens that cause
      problems with either the direct manipulation of the repository
      (if there is local network security between the repository and
      the playback mechanism) and with delegated requests.  Such
      authentication can be circumvented by tunneling the playback
      requests.  However, requests that require delegating authority
      across network boundaries will always need to provide a
      challenge to the original agent.  Clearly this can only succeed
      under certain network architecture plans.

Happy holidays to all,

-bryan