Return-Path: Delivered-To: apmail-incubator-chemistry-dev-archive@minotaur.apache.org Received: (qmail 63622 invoked from network); 17 May 2010 14:14:22 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 May 2010 14:14:22 -0000 Received: (qmail 53815 invoked by uid 500); 17 May 2010 14:14:22 -0000 Delivered-To: apmail-incubator-chemistry-dev-archive@incubator.apache.org Received: (qmail 53704 invoked by uid 500); 17 May 2010 14:14:21 -0000 Mailing-List: contact chemistry-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: chemistry-dev@incubator.apache.org Delivered-To: mailing list chemistry-dev@incubator.apache.org Received: (qmail 53696 invoked by uid 99); 17 May 2010 14:14:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 May 2010 14:14:21 +0000 X-ASF-Spam-Status: No, hits=-4.4 required=10.0 tests=AWL,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stephan.klevenz@sap.com designates 155.56.66.98 as permitted sender) Received: from [155.56.66.98] (HELO smtpgw.sap-ag.de) (155.56.66.98) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 May 2010 14:14:16 +0000 From: "Klevenz, Stephan" To: "chemistry-dev@incubator.apache.org" Date: Mon, 17 May 2010 16:13:52 +0200 Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation Thread-Topic: [jira] Resolved: (CMIS-124) Client Runtime Implementation Thread-Index: Acrx2Aa6RbWss/BJRDuZ1KeRFEC8GAAA02tQAADevXAAALbUsAABAE4wADGniSAAxqSnUA== Message-ID: References: <32720624.38441272987542672.JavaMail.jira@thor> <0092AA4B-D2D2-4428-B657-0177FFA8BABA@sourcesense.com> <56C255F88C54014E92512ED3E7848F9404B583B9@MUCXGC1.opentext.net> <56C255F88C54014E92512ED3E7848F9404B5842D@MUCXGC1.opentext.net> <56C255F88C54014E92512ED3E7848F9404B587F9@MUCXGC1.opentext.net> <56C255F88C54014E92512ED3E7848F9404B58812@MUCXGC1.opentext.net> <56C255F88C54014E92512ED3E7848F9404B5882E@MUCXGC1.opentext.net> <56C255F88C54014E92512ED3E7848F9404B588F8@MUCXGC1.opentext.net> In-Reply-To: <56C255F88C54014E92512ED3E7848F9404B588F8@MUCXGC1.opentext.net> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 distr= ibuted accordingly to the new packages.=20 Are there any objectives to this proposal? If you agree then I'm not sure w= hen 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 b= etter 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 t= ype indicator PropertyData could be an id property, a string proper= ty, a HTML property or an URI property. If we want to get rid of the sub-in= terfaces, 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 interf= ace. E.g. PropertyDataTime extends PropertyData{}. Isn't= it sufficient just to have PropertyData?=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 CMI= S Bindings API sounds reasonable.=20 Even if we consolidate a few (which doesn't make them more useable!), the m= agnitude will not change.=20 What's the issue? The size of the Jar? The Client API user will only deal w= ith 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 pac= kage *.commons.api that contains more than 50 interfaces (!). Removing unne= cessary 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 w= rote: > Hi Florent, > > The Property*Defintion interfaces are actually different and cannot be co= llapsed. 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 getPropertyValue(String id); > =A0 =A0 List getPropertyMultivalue(String id); > > After the first release is done, I'll propose to change it to: > =A0 =A0 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 > 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 = wrote: >> Hi Ugo, >> >> "Somewhat stable" is the right term. Most of the merger refactoring task= s are done. Only the type manager implementation is still missing. >> >> I cannot promise that there will no changes within the next weeks, but w= e 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 basic= s are still valid but some names have changed. >> >> >> Thank you. What I actually would like to know is whether the current API= s are considered somewhat stable, after the Chemistry/OpenCMIS merge. I can= live with an incomplete and buggy implementation (and try to contribute fi= xes, as much as possible), but less so if a complete redesign is still in t= he 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