(Very late answer...) I see three uses cases:
1. having a reference implementation of a server 2. having an small embeddable store for lightweight applications 3. having a persistence framework so that things like unit tests can be written for third-party CMIS applications. The way I see this: 1. is I think a big endeavor as you'd want something relatively efficient, with nice features, etc. It's basically the Jackrabbit way and I wouldn't spend time on this. 2. would also need some efficiency and care to code things properly, although it could avoid implementing everything in the spec. 3. is more interesting I think, as long as it's clearly stated to the users of the code that this if for testing purposes and that the code is not optimized at all. But such a persistence can be done simply by Java serialization so I think it's not a huge task. Florent On Tue, Jun 22, 2010 at 1:47 PM, Klevenz, Stephan <[email protected]> wrote: > After getting now more practice and experience with using the OpenCMIS > library for application development I would like to say that the existence of > the InMemory store is a benefit. InMemory enables to use OpenCMIS immediately > without having high effort in installation or depending on decisions which > concrete store to be used for an application finally. The hurdle to use > OpenCMIS is very low. InMemory supports perfectly Maven and JUnit based > development and we are using it for application development scenarios. > > Unfortunately there are limitations with InMemory if development scenario > becomes more complex. In complex scenarios for example a centralized and > reliable store is required and the purpose is not only development but also > to have something like a reference store for applications that make use of > OpenCMIS library. > > The basic idea is to support a standard store for OpenCMIS within the > Chemistry project. We did not think too much about how to get it or have a > concrete implementation in mind. It's more about your opinion about having a > standard store within Chemistry. > > Are you interested in follow up this discussion? > > Regards, > Stephan > > > > Stephan Klevenz > Development Architect > TD Core UI Infr (AG) > ECM-I > SAP AG > Dietmar-Hopp-Allee 16 > 69190 Walldorf, Germany > T +49 6227 7-65878 > F +49 6227 78-36242 > M +49 160 90432408 > E [email protected]<mailto:[email protected]> > www.sap.com > > Pflichtangaben/Mandatory Disclosure Statements: > http://www.sap.com/company/legal/impressum.epx > > Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich > erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine > Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte > benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. > > This e-mail may contain trade secrets or privileged, undisclosed, or > otherwise confidential information. If you have received this e-mail in > error, you are hereby notified that any review, copying, or distribution of > it is strictly prohibited. Please inform us immediately and destroy the > original transmittal. Thank you for your cooperation. > > > > > -- 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
