anchor.diff:  ** Each file in the VFS supports change tracking, revision control, and update notification
   ** File types can be associated with custom viewers and editors
   ** The contents of the VFS can also be searched using a performant full-text search engine
  -    (TODO: is this correct? I think this is the purpose of uberfire-metadata)
   * Application components can be written in Java or JavaScript. Components can interoperate
     regardless of which language they are implemented in.
   
  
positive.code: * FileSystemType (client + server)
  * Clustering (see also UberFire Commons)
  * IO Services (Clustered service, Search Service, Watch Service)
  
  
  UberFire JS Concepts
  ~~~~~~~~~~~~~~~~~~~~
  
negative.code: which contains a mix of server-only definitions shared client/server definitions.
  
  * Clustering (server-only, see also UberFire I/O)
  * Data
   ** Pair, a generic 2-tuple (client + server)
   ** Triple, a generic 3-tuple (client + server)
   ** Cacheable, interface that provides explicit visibility of cached data.
  * Lock Service (server-only)
  * Messaging (server-only, distinct from Errai Bus messages)
  +
  Provide for clustered deployments;
  ** AsyncCallback
  +
  TODO
  ** MessageHandler
  +
  TODO
  ** MessageHandlerResolver
  +
  TODO
  ** MessageService
  +
  TODO
  ** MessageType
  +
  TODO
  
  * CDI Startup Beans (the @Startup annotation) (server-only)
  * PortablePreconditions (client + server), a collection of static methods for checking common preconditions (reference not null, list not empty, etc.)
  ** Note: Errai has a shared class called Assert which serves a similar purpose
  * Preconditions (server-only), precondition checks that are not GWT-translatable
  
  UberFire I/O Concepts
  ~~~~~~~~~~~~~~~~~~~~~
  
  