===============================================================================
Apache Jackrabbit SPI - TODOs
===============================================================================

NOTE: This list only contains major open issues.
      Minor known issues and problems are marked throughout the code with TODO.


1) RepositoryService  (missing)
   
   missing implementation for:
   > Clone
   > RegisterNodeType
   > ReregisterNodeTypes
   > UnregisterNodeType
   > Subscribe/Unsubscribe und Event retrieval
   
   
2) RepositoryService  (improve)

   param consistency
   while in the very first draft ids, values and names were represented
   by String and Stream only, we currently have a inconsistent mixture
   of separate interfaces/classes for ids and names, while values are
   still represented by String/Stream only mentioning in the comments
   that values are meant to be in a qualified form in case of property
   type Name and Path.
   Second it seems inconsistent that an interface is defined for ItemId,
   while the QName class from jackrabbit commons is used (see also FAQ).


3) RepositoryService, Batch (improve)

   > check consistency of throw clauses.


4) Usage of SPI ids instead of JR-ids in jcr2spi  (missing)

   a) using SPI NodeIds which don't have a mandatory UUID, requires fundamental
   rework of the transient space (modified after jackrabbit code).
   this mainly affects the following methods:
      > remove
      > move
      > reorder
      > refresh


   In addition the code has been marked with // TODO: TO-BE-FIXED comments. 


5) Locking: SessionScoped locks (missing)
   
   Up to now, the SPI does not provide the possibility to transport the lock
   scope. We would argue, that the 'server' does not have to care about the
   scope of a lock.
   
   Therefore Lock.isSessionScoped does not return the proper value unless the
   Session is the lock holder. 

   If the scope flag is included in RepositoryService.lock the following steps
   are required:

     > RS.lock      -> additional param
     > RSImpl.lock
       iss=fales    -> scope = Scope.EXCLUSIVE
       iss=true     -> ItemResourceConstants.EXLUSIVE_SESSION
     > LockInfo     -> additional method
     > LockInfoImpl -> retrieve scope from lockDiscovery
     > LockImpl     -> mod. constructor (no iss flag)
                    -> retrive isSessionScoped flag from the lockInfo
                    -> remove todo bei getLock() methode, der
                       zur zeit 'iss' auf false setzt.


6) Locking: Handling of LockTokens  (problem)

   There are 2 methods in JSR 170 that deal with handling of LockTokens:
   Session.addLockToken, Session.removeLockToken. The spec defines, that
    
   a) session-scoped locks may not be transfered to another session
   b) only one Session object must be lock holder. adding a token that is
      still present with another session is not possible.

   This causes the following issues with the SPI

   a) session-scoped locks are currently not implemented properly (see 5)
   b) no session info is transfered over the SPI boundary nor are the addLT/
      removeLT methods passed over the SPI.
      consequently its (with the current design) not possible to detect, whether
      the given locktoken is still hold by another Session object.


7) Observation (missing)

   - RepositoryService: return value (events) von RS-calls
   - RepositoryService: subscription/event-discovery completely missing

   - EventImpl: with the current setup spi2dav connects to a default 
     jackrabbit jcr-server reflecting JCR calls. consequently event discovery
     will only return JCR events.
     Additional information defined by the SPI Event interface cannot be 
     retrieved from the information sent by jcr-server.


8) AddNode (problem)
 
   In order to be able to return the created Node, it would be required to
   now its Id if the operation succeeded, since the Node name passed to the
   call may not identify the new Node in case of same-name-siblings.


9) Merge (problem)
   
   similar to 8)
   The call defines a NodeIterator as return value.


10) Transactions (work in progress)

   Definition of XASessionInfo must be reviewed.


11) SessionImpl.switchWorkspace(String) used to create session on other 
    workspace for current subject. Missing implementation


12) Extract interface for ItemState and derived classes


13) AccessManager.canRead() seems useless, since the jcr2spi client is only
    able to access Items it can read anyway. Remove method and calls to it?