F2F progress

[Florent Guillaume <fg...@nuxeo.com>]

Here's the notes from our discussions this afternoon. This is a bit
cryptic but the essentials are there. Please ask if clarification is
needed, we'll put up a synthesized version before the end of the week
anyway.


* DTOs
  - repo info & capabilities as unified DTOs
  - types as DTOs but client-side can be extended with getChildrenTypes & co
  - value types? BigInteger vs long, BigDecimal vs double, etc.
    - we have to keep them (used as is by JAXB anyway)
    - add some convenience methods to get to long/double
    - ContentStream: getLength returns long or -1 if not provided,
getBigLength returns BigInteger and may be null if not provided
  - naming? SomethingData -> Something? Use nice names for the
high-level client API. This is the case currently. And keep
SomethingData for the low-level interface.
  - Boolean vs boolean
    - types, capabilities, etc: TBD
    - properties: have to be kept Boolean (same as other non-primitive types)
  - Extensions
    - how to access them client-side? allow vendor-specific object
factories to create other implementations of the client interfaces
    - granularity of the factory registration? TBD
    - SPI: allowed everywhere in the schemas -> keep them everywhere
    - adapter or cast system to get to extension data

* PagingList
  - try a new interface without nested pages, but a skipTo() added
  - close() method
    - but how to plug that into the client-side level?
    -> prototype this

* 9 vs 1 interface on the client side
  - 9 provide clarity to the user as it reflects the spec

* "Inclusion" parameter
  - in client API there's an OperationContext (optional)
  - in server SPI there's no need for it

* Exceptions
  - make them all unchecked
  - document them in signatures and javadoc
  - not reuse standard java ones
  - flat hierarchy

* Types
  - TypeManager interface
  - client-side, the Session gives access to the Repository and the TypeManager

* fallback to SPI on the client-side?
  - not needed as one goal of the client API is to provide access to
all of the protocol
  - provider is nevertheless available if someone wants "optimized" calls

* CMISQL Query parser
  - put in server support
  - must implement the fulltext language parsing as well


Florent


-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87