Hi Florian,
On Thu, Nov 25, 2010 at 5:45 PM, Florian Müller
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 t
Hi Florent,
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 d
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 "
reset() discards all changes made to the object.
refreshAndReset() discards all changes and refreshes the underlying
CmisObject.
Not sure if we need them. I thought they might be handy.
- Florian
On 22/11/2010 13:38, Florent Guillaume wrote:
Yet another question:
What's the expected seman
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 chang
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
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
wrote:
> Hi all,
>
> Merge is done. Please test and provide feedback.
>
>
> Thanks,
>
> Fl
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 obje
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 wou
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 interfac
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
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
poss
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
wrote:
> Hi all,
>
> If nobody objects, I will merge the client API refactoring branch into trunk
> this Wednesday.
> If there are any re
13 matches
Mail list logo
