Perhaps I've been influenced by the Jackrabbit stack, but I was
expecting two distinct apis. The client API (equivalent to JCR
javax.jcr) and the SPI (equivalent to org.apache.jackrabbit.spi). The
Jackrabbit SPI has few dependencies on JCR API (mostly Exceptions).
The JCR API has no dependency on SPI.
The split could bring:
- simpler/consistent API for client developer
- distinct state management between API and SPI
- API implementations without SPI dependency
Admittedly, I haven't put much thought into this, and the nature of
CMIS may mean this pattern does not fit.
Is this something that's been explored already?
Regards,
Dave
On 7 Jul 2009, at 14:33, Florent Guillaume wrote:
On 7 Jul 2009, at 15:12, David Caruana wrote:
I would like to better understand the chemistry-api module. It's
probably easiest to describe my current understanding and ask
questions, then you can correct me where applicable.
My understanding...
The intent is to provide:
1) Java API for clients who wish to interact with a CMIS server
that's simple to use and independent of protocol binding.
2) Java SPI for:
a) repository providers who wish to add a CMIS provider facade
to their repository
b) protocol providers who wish to map CMIS client requests to
protocol and map protocol to CMIS provider
3) An API to SPI adaptor (for in-process access to provider, or
protocol access to provider via API)
Questions...
1) chemistry-api seems to consist of both API and SPI which are
dependent on each other. Is that correct? Or is chemistry-api
currently only focused on SPI?
API and SPI are in the same chemistry-api module. The "API" part is
really just the Connection, CMISObject, Document and Folder classes.
There are many dependencies on all the enums, property types and so
on, which have to live in the SPI and be available to applications,
so it didn't make sense to me to have them live in an SPI module
that clients would have to import anyway.
So the separation between API and SPI is conceptual, for
implementors. Clients don't have to know that there's a SPI
available, but if they wish they can access it for specialized
efficient methods (fine-grained query would be an obvious one).
2) What is the relationship between SPI, Repository and Connection?
From a Repository you get a SPI or a Connection, whatever is best
for your app. From an existing connection you can also get to the
underlying SPI if needed.
The way to get a Repository should go through some RepositoryManager
but this isn't implemented yet. Today we still construct them by
hand according to the implementation we know we want, see the unit
tests.
3) For a CMIS client of chemistry-api what is the typical call
sequence for interacting with a CMIS server? I assume...
a) get Repository (with protocol specific factory)
Which ideally should be a lookup through a static RepositoryManager
or something like that.
b) Repository.getConnection() (although Repository also
provides access to types and SPI outside of connection)
c) connection.xxx()
d) connection.close()
Yes.
4) Is it the plan to allow Credentials to be provided to the API?
e.g. on establishing connection
Yes.
5) Will RepositoryService eventually be the entry-point for a client?
Hm I'd forgotten about that interface. Yes, that's the one I meant
by "RepositoryManager".
6) Is it the plan to provide a factory mechanism (like JCR) for
providing the entry-point API interface, bound to a chosen and
configured SPI client protocol implementation?
Yes.
Sorry, lots of questions. I understand things are moving quickly,
Just getting up to speed.
No problem, it's good to have more eyeballs on the code.
Florent
--
Florent Guillaume, Head 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
