Re: Client API refactoring branch merge
Hi Florian, I agree that inheritance of implementation would be difficult. I was more thinking about inheritance of the interfaces. The contract is the same, the javadoc is the same, I really think the common interfaces shouldn't be duplicated (DRY). In that case having six new base interfaces would just clean things up IMHO. Regarding adapters, yes their implementation needs to be designed for CMIS, but not the interfaces. For instance you could adapt to InputStream to get a direct view of the content stream, or adapt to Map to get a Map-like view of the document's properties. Or adapt to pre-existing vendor interfaces. Florent On Fri, Nov 19, 2010 at 9:38 PM, Florian Müller florian.muel...@alfresco.com wrote: Hi Florent, Inheritance would be very difficult. The implementations of Document and TransientDocument, for example, are too different. We could create common interfaces that cover all property getters. That would clean up the existing interfaces a bit, but would also create six new interfaces that I can't see a real use case for. Let me know if I'm missing something. My idea behind the CmisObjectAdapter interface was to make the whole thing more type save. Could you provide a sample use case that would require reusing a third-party interface? Doesn't an adapter need to be designed for CMIS? - Florian On 19/11/2010 18:58, Florent Guillaume wrote: Hi, There's a lot of duplication of methods from, for instance, Document and TransientDocument. Couldn't one inherit from the other (I guess not), or couldn't they have a common base interface? Also I don't think we need a base CmisObjectAdapter interface, it's actually useful to be able to adapt to any third-party interface. I'll deal with making getAdapter not need that (and use generics). Florent On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller florian.muel...@alfresco.com 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 RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Client API refactoring branch merge
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 florian.muel...@alfresco.com 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 RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Client API refactoring branch merge
Yet another question: What's the expected semantics of org.apache.chemistry.opencmis.client.api.TransientCmisObject.reset() and refreshAndReset()? Florent On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller florian.muel...@alfresco.com 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 RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Client API refactoring branch merge
Hi Florent, Actually, the contract and the JavaDoc are not the same for all methods. Take getName() as an example. For CmisObject it returns the name of the object as it was loaded. For TransientObject it returns the current state of the name property in the transient object. If you have changed the name and haven't saved the object yet, it doesn't return the name that was loaded. I have no strong opinion on the adapter design. Accepting an arbitrary interface doesn't feel right to me, but if you have a use case, we can change that. - Florian On 22/11/2010 09:56, Florent Guillaume wrote: Hi Florian, I agree that inheritance of implementation would be difficult. I was more thinking about inheritance of the interfaces. The contract is the same, the javadoc is the same, I really think the common interfaces shouldn't be duplicated (DRY). In that case having six new base interfaces would just clean things up IMHO. Regarding adapters, yes their implementation needs to be designed for CMIS, but not the interfaces. For instance you could adapt to InputStream to get a direct view of the content stream, or adapt to Map to get a Map-like view of the document's properties. Or adapt to pre-existing vendor interfaces. Florent On Fri, Nov 19, 2010 at 9:38 PM, Florian Müller florian.muel...@alfresco.com wrote: Hi Florent, Inheritance would be very difficult. The implementations of Document and TransientDocument, for example, are too different. We could create common interfaces that cover all property getters. That would clean up the existing interfaces a bit, but would also create six new interfaces that I can't see a real use case for. Let me know if I'm missing something. My idea behind the CmisObjectAdapter interface was to make the whole thing more type save. Could you provide a sample use case that would require reusing a third-party interface? Doesn't an adapter need to be designed for CMIS? - Florian On 19/11/2010 18:58, Florent Guillaume wrote: Hi, There's a lot of duplication of methods from, for instance, Document and TransientDocument. Couldn't one inherit from the other (I guess not), or couldn't they have a common base interface? Also I don't think we need a base CmisObjectAdapter interface, it's actually useful to be able to adapt to any third-party interface. I'll deal with making getAdapter not need that (and use generics). Florent On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller florian.muel...@alfresco.comwrote: 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
Re: Client API refactoring branch merge
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 florian.muel...@alfresco.com 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
Re: Client API refactoring branch merge
Hi, There's a lot of duplication of methods from, for instance, Document and TransientDocument. Couldn't one inherit from the other (I guess not), or couldn't they have a common base interface? Also I don't think we need a base CmisObjectAdapter interface, it's actually useful to be able to adapt to any third-party interface. I'll deal with making getAdapter not need that (and use generics). Florent On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller florian.muel...@alfresco.com 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 RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Client API refactoring branch merge
Hi Florent, Inheritance would be very difficult. The implementations of Document and TransientDocument, for example, are too different. We could create common interfaces that cover all property getters. That would clean up the existing interfaces a bit, but would also create six new interfaces that I can't see a real use case for. Let me know if I'm missing something. My idea behind the CmisObjectAdapter interface was to make the whole thing more type save. Could you provide a sample use case that would require reusing a third-party interface? Doesn't an adapter need to be designed for CMIS? - Florian On 19/11/2010 18:58, Florent Guillaume wrote: Hi, There's a lot of duplication of methods from, for instance, Document and TransientDocument. Couldn't one inherit from the other (I guess not), or couldn't they have a common base interface? Also I don't think we need a base CmisObjectAdapter interface, it's actually useful to be able to adapt to any third-party interface. I'll deal with making getAdapter not need that (and use generics). Florent On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller florian.muel...@alfresco.com 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
Re: Client API refactoring branch merge
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
Re: Client API refactoring branch merge
Hi, I should be fixing the rendition bug tonight or tomorrow, so a merge on Wednesday is fine for me. Florent On Mon, Nov 15, 2010 at 2:50 PM, Florian Müller florian.muel...@alfresco.com 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 RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
