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
