Hi Dave,
I considered that initially (follow the Jackrabbit model where API and
SPI are completely separate), but it was more cumbersome than anything.
CMIS is primarily defined by its abstract domain model, which is
closely mirrored in the protocols. This is the lowest level that
you'll get in a CMIS framework, so I called that the SPI. On top of
that, we had to build a more abstract API for application users, but
it doesn't make sense to redefine all the classes for enums, types,
property definitions, etc., as these are all useful to the high level
API in any case.
I don't see the division between the two as inconsistent or a source
of complexity, the two levels may be useful at different time even for
an application developers. And they aren't mixed in the same
interface, you actually have to call getSPI() to get one from a
Connection.
Having API implementations without the SPI dependency isn't something
I want. Developers *will* need in many cases, for efficiency, to go
below the API to get efficient CMIS behavior, so I want them to have
access to the SPI as well. We could do a SPI-to-API set of base
classes if implementors don't want to code the SPI level, but it
wouldn't be as efficient as coding it yourself.
I'm not sure what "distinct state management" means, could you expand?
Cheers,
Florent
On 7 Jul 2009, at 19:00, David Caruana wrote:
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
--
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
