I wonder if it is possible to implement JCR without the SPI? What would be the next steps to get a running JCR implementation?
Best, Michael -----Ursprüngliche Nachricht----- Von: Florent Guillaume [mailto:[email protected]] Gesendet: Dienstag, 7. Juli 2009 15:33 An: [email protected] Betreff: Re: API vs SPI 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
