Hi Florian, On Thu, Nov 25, 2010 at 5:45 PM, Florian Müller <[email protected]> wrote: > Well, I actually just completed what was unfinished before. Some interfaces > were Serializable, some weren't. > The interfaces don't have to be Serializable, but the implementations, that > we are shipping have to be in order to support the HTTP session scenario. > In other words, I don't see a strong reason to keep the interfaces > Serializable. We could change that.
Ok, glad we're on the same page. > On the other hand, how do you make sure that a statefull implementation > behaves exactly like a the default stateless implementations? An application > that uses the OpenCMIS interface should not have to care which > implementation it is using underneath. Agreed. In my case I have a set of unit test that test the same code with AtomPub, SOAP and my local bindings. > And, if the statefull implementation behaves like the stateless > implementation, why is the local binding not sufficient? Are you hitting an > issue with the local binding ? The OpenCMIS-provided local bindings are implemented at the SPI level (as they should) which means use of DocumentImpl, AbstractCmisObject, ObjectDataImpl & co which have a heavy cost in terms of memory and copying. By specializing the implementation I can directly reuse my native objects and avoid a lot of overhead. Florent > > - Florian > > > On 25/11/2010 15:12, Florent Guillaume wrote: >> >> I'm still having a hard time coming to terms with some of the aspects >> of the refactored code. >> >> I don't see why there's a link between a high-level interface like >> CmisObject and the fact that it has to be Serializable. >> Session/CmisObject/etc. are deemed "client" interfaces but they are >> really only "high-level" interfaces, the API as opposed to the SPI. >> The fact that the default implementation uses a stateless >> client/server model (which allows for a Serializable implementation) >> doesn't mean that all implementations have to be like that. >> >> In my local client bindings my implementations of these interfaces are >> tied to a connection-like object which is not Serializable. And nobody >> will try to put them in a HTTP session, it's perfectly all right for >> them. >> >> So I'd like to remove the Serializable interface from Session, >> CmisObject& co and put it on SessionImpl, AbstractCmisObject, etc. >> >> Florent >> >> >> On Mon, Nov 22, 2010 at 3:44 PM, Florian Müller >> <[email protected]> wrote: >>> >>> The requirement that Session objects and objects attached it should be >>> Serializable is not new. It has been there right from the beginning of >>> OpenCMIS but wasn't implemented properly. >>> >>> We want to make sure that you can put a Session object into a >>> HttpSession. >>> That allows Servlet engines to swap out HttpSessions to disk or transfer >>> sessions to other cluster nodes. >>> >>> >>> - Florian >>> >>> >>> On 22/11/2010 13:18, Florent Guillaume wrote: >>>> >>>> Another question: >>>> >>>> Why the new requirement that Session, CmisObject& co be Serializable? >>>> In my local bindings, sessions and objects are created from >>>> non-Serializable objects from the underlying repository API, and I >>>> cannot easily make them truly Serializable. I have underlying >>>> connection-like objects that come from a transactional context which >>>> are definitely not Serializable. >>>> What do you think? >>>> >>>> Florent >>>> >>>> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller >>>> <[email protected]> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Merge is done. Please test and provide feedback. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Florian >>>>> >>>>> >>>>> On 15/11/2010 13:50, Florian Müller wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> If nobody objects, I will merge the client API refactoring branch into >>>>>> trunk this Wednesday. >>>>>> If there are any reasons not to merge, please let me know as soon as >>>>>> possible! >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Florian >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > > -- 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
