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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo
