Mailing-List: contact chemistry-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: chemistry-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of fmueller@opentext.com
 designates 149.235.128.48 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation
Date: Mon, 17 May 2010 17:15:27 +0200
Message-ID: <56C255F88C54014E92512ED3E7848F9404BE4269@MUCXGC1.opentext.net>
In-Reply-To: 
 <C27DDAD1D92BC146BB4D72371796C6A80EC4FC578D@DEWDFECCR06.wdf.sap.corp>
Thread-Topic: [jira] Resolved: (CMIS-124) Client Runtime Implementation
Thread-Index: 
 Acrx2Aa6RbWss/BJRDuZ1KeRFEC8GAAA02tQAADevXAAALbUsAABAE4wADGniSAAxqSnUAAC7R6g
References: <32720624.38441272987542672.JavaMail.jira@thor>
 <0092AA4B-D2D2-4428-B657-0177FFA8BABA@sourcesense.com>
 <C27DDAD1D92BC146BB4D72371796C6A80EA11AF749@DEWDFECCR06.wdf.sap.corp>
 <56C255F88C54014E92512ED3E7848F9404B583B9@MUCXGC1.opentext.net>
 <E44B1651-CAD8-4EF8-B5B3-D599FE842F24@sourcesense.com>
 <56C255F88C54014E92512ED3E7848F9404B5842D@MUCXGC1.opentext.net>
 <AANLkTikL9ABZ34E-nJ77VHTi2Rci4n6P_fwx8-pD9xlr@mail.gmail.com>
 <56C255F88C54014E92512ED3E7848F9404B587F9@MUCXGC1.opentext.net>
 <AANLkTil0c6Bc7d7RwvR8eX2nBZQq9g5eiJj7jlA03lz0@mail.gmail.com>
 <56C255F88C54014E92512ED3E7848F9404B58812@MUCXGC1.opentext.net>
 <C27DDAD1D92BC146BB4D72371796C6A80EA12C7555@DEWDFECCR06.wdf.sap.corp>
 <56C255F88C54014E92512ED3E7848F9404B5882E@MUCXGC1.opentext.net>
 <C27DDAD1D92BC146BB4D72371796C6A80EA12C765B@DEWDFECCR06.wdf.sap.corp>
 <56C255F88C54014E92512ED3E7848F9404B588F8@MUCXGC1.opentext.net>
 <C27DDAD1D92BC146BB4D72371796C6A80EC4FC578D@DEWDFECCR06.wdf.sap.corp>
From: =?iso-8859-1?Q?Florian_M=FCller?= <fmueller@opentext.com>
To: <chemistry-dev@incubator.apache.org>

+1
Looks good.

If we want to change it before the first release, then we should change =
it soon.


- Florian

-----Original Message-----
From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]=20
Sent: Montag, 17. Mai 2010 16:14
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation

Hi,

The commons.api package contains currently these interface groups:

SPI Service interfaces
Extension Data interfaces
Type Definition interfaces
Server interfaces

I would like to suggest the following change in package structure:

org.apache.chemistry.opencmis.commons               // unchanged
org.apache.chemistry.opencmis.commons.enums         // unchanged
org.apache.chemistry.opencmis.commons.exceptions    // unchanged
org.apache.chemistry.opencmis.commons.data          // interfaces =
extending ExtensionData
org.apache.chemistry.opencmis.commons.definitions   // interfaces =
extending PropertyDefinion=20
org.apache.chemistry.opencmis.commons.spi           // service =
interfaces
org.apache.chemistry.opencmis.commons.server        // server interfaces

The package commons.api is deleted and contained interfaces should be =
distributed accordingly to the new packages.=20

Are there any objectives to this proposal? If you agree then I'm not =
sure when to make the change?=20

Regards,
Stephan


-----Original Message-----
From: Florian M=FCller [mailto:fmueller@opentext.com]=20
Sent: Donnerstag, 13. Mai 2010 17:31
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation

Hi Stephan,

Moving stuff around shouldn't be a big deal. If you have a proposal for =
a better package structure, let us know.

The interfaces that extend PropertyData are important for the binding =
layer. I need to know the data type during the conversion step. Without =
a data type indicator PropertyData<String> could be an id property, a =
string property, a HTML property or an URI property. If we want to get =
rid of the sub-interfaces, we have to add something like=20

PropertyType getPropertyType();

to the PropertyData interface.=20


Florian

-----Original Message-----
From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]=20
Sent: Mittwoch, 12. Mai 2010 17:35
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation

Simple things could help:

a) I don't want to collapse property definition classes, because they =
have type dependent methods. But it would help just to move them into a =
separate package. The use case is intellisense feature of the IDE. =
Currently it is hard to select what you want.

b) All interfaces derived from PropertyData do not really extend the =
interface. E.g. PropertyDataTime extends =
PropertyData<GregorianCalendar>{}. Isn't it sufficient just to have =
PropertyData<T>?=20

Regards,
Stephan


-----Original Message-----
From: Florian M=FCller [mailto:fmueller@opentext.com]=20
Sent: Mittwoch, 12. Mai 2010 17:02
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation

CMIS defines almost 200 different structures. So, 50 interfaces for the =
CMIS Bindings API sounds reasonable.=20
Even if we consolidate a few (which doesn't make them more useable!), =
the magnitude will not change.=20

What's the issue? The size of the Jar? The Client API user will only =
deal with a few of them.


Florian

-----Original Message-----
From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]=20
Sent: Mittwoch, 12. Mai 2010 16:34
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation

Hi,

I'm also interested into this discussion. There is a general issue with =
package *.commons.api that contains more than 50 interfaces (!). =
Removing unnecessary interfaces and re-structuring would make sense.

Regards,
Stephan


-----Original Message-----
From: Florian M=FCller [mailto:fmueller@opentext.com]=20
Sent: Mittwoch, 12. Mai 2010 16:01
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation

That doesn't really sound object oriented...
We should discuss this later with some use cases.=20

Florian

-----Original Message-----
From: Florent Guillaume [mailto:fg@nuxeo.com]=20
Sent: Mittwoch, 12. Mai 2010 15:35
To: chemistry-dev
Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation

I know but it's rather easy to add all of:
    T getMinValue();
    T getMaxValue();
    BigInteger getMaxLength();
    DecimalPrecision getDecimalPrecision();
    DateTimeResolution getDateTimeResolution();
on the single PropertyDefinition class, and make them throw exceptions
when not called on the suitable kind of property.

Florent


On Wed, May 12, 2010 at 3:20 PM, Florian M=FCller =
<fmueller@opentext.com> wrote:
> Hi Florent,
>
> The Property*Defintion interfaces are actually different and cannot be =
collapsed. Compare PropertyDateTimeDefinition with =
PropertyDecimalDefinition, for example.
>
>
> - Florian
>
> -----Original Message-----
> From: Florent Guillaume [mailto:fg@nuxeo.com]
> Sent: Mittwoch, 12. Mai 2010 14:49
> To: chemistry-dev
> Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation
>
> Yes, with use there's some things that may appear as suboptimal in the
> current API and we cannot promise no changes. But nothing
> revolutionary will come I'm sure.
>
> As an example of changes that may or may not appear:
>
> I don't like this part of the high-level API and find it hard to use:
> =A0 =A0<T> T getPropertyValue(String id);
> =A0 =A0<T> List<T> getPropertyMultivalue(String id);
>
> After the first release is done, I'll propose to change it to:
> =A0 =A0<T> T getPropertyValue(String id);
>
> Which would returns a single value for a single-valued property, and a
> list for a multi-valued property.
>
>
> I'd also like to fold all the PropertyDecimalDefinition,
> PropertyStringDefinition, etc. into the single PropertyDefinition<T>
> because the sub-interfaces don't add much IMHO. Proposal to come.
>
>
> (I'm not proposing to do it earlier as I really want a first release
> out the door and have little enough time to work on this right now...
> and I'm in vacation for the next 10 days.)
>
> Florent
>
>
>
> On Sun, May 9, 2010 at 6:52 PM, Florian M=FCller =
<fmueller@opentext.com> wrote:
>> Hi Ugo,
>>
>> "Somewhat stable" is the right term. Most of the merger refactoring =
tasks are done. Only the type manager implementation is still missing.
>>
>> I cannot promise that there will no changes within the next weeks, =
but we certainly will not redesign the API.
>>
>>
>> - Florian
>>
>>
>> -----Original Message-----
>> From: Ugo Cei [mailto:u.cei@sourcesense.com]
>> Sent: Freitag, 7. Mai 2010 19:18
>> To: chemistry-dev@incubator.apache.org
>> Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime =
Implementation
>>
>>
>> On May 7, 2010, at 3:44 PM, Florian M=FCller wrote:
>>
>>> Hi Ugo,
>>>
>>> It's there for quite some time now.
>>>
>>> This page explains how you get and compile it: [1]
>>> The API introduction pages [2] and [3] are a bit out-of-date. The =
basics are still valid but some names have changed.
>>
>>
>> Thank you. What I actually would like to know is whether the current =
APIs are considered somewhat stable, after the Chemistry/OpenCMIS merge. =
I can live with an incomplete and buggy implementation (and try to =
contribute fixes, as much as possible), but less so if a complete =
redesign is still in the pipeline.
>>
>> =A0 =A0 =A0 =A0Ugo
>>
>> --
>> Ugo Cei
>> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>>
>>
>
>
>
> --
> Florent Guillaume, Director of R&D, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> http://www.nuxeo.com =A0 http://www.nuxeo.org =A0 +33 1 40 33 79 87
>


--=20
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