Go ahead. We should solve those general stuff as soon as possible. Florian
-----Original Message----- From: Stephan Klevenz [mailto:[email protected]] Sent: Mittwoch, 19. Mai 2010 08:37 To: [email protected] Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation Hi, If there are no more objectives then I will re-factor the commons package ASAP. A Jira issue is created. Regards, Stephan Am 17.05.2010 um 17:15 schrieb Florian Müller: > +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:[email protected]] > Sent: Montag, 17. Mai 2010 16:14 > To: [email protected] > 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 > 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. > > Are there any objectives to this proposal? If you agree then I'm not sure > when to make the change? > > Regards, > Stephan > > > -----Original Message----- > From: Florian Müller [mailto:[email protected]] > Sent: Donnerstag, 13. Mai 2010 17:31 > To: [email protected] > 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 > > PropertyType getPropertyType(); > > to the PropertyData interface. > > > Florian > > -----Original Message----- > From: Klevenz, Stephan [mailto:[email protected]] > Sent: Mittwoch, 12. Mai 2010 17:35 > To: [email protected] > 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>? > > Regards, > Stephan > > > > > > > > -----Original Message----- > From: Florian Müller [mailto:[email protected]] > Sent: Mittwoch, 12. Mai 2010 17:02 > To: [email protected] > 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. > Even if we consolidate a few (which doesn't make them more useable!), the > magnitude will not change. > > 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:[email protected]] > Sent: Mittwoch, 12. Mai 2010 16:34 > To: [email protected] > 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üller [mailto:[email protected]] > Sent: Mittwoch, 12. Mai 2010 16:01 > To: [email protected] > 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. > > Florian > > -----Original Message----- > From: Florent Guillaume [mailto:[email protected]] > 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üller <[email protected]> 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:[email protected]] >> 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: >> <T> T getPropertyValue(String id); >> <T> List<T> getPropertyMultivalue(String id); >> >> After the first release is done, I'll propose to change it to: >> <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üller <[email protected]> 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:[email protected]] >>> Sent: Freitag, 7. Mai 2010 19:18 >>> To: [email protected] >>> Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation >>> >>> >>> On May 7, 2010, at 3:44 PM, Florian Müller 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. >>> >>> Ugo >>> >>> -- >>> 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 http://www.nuxeo.org +33 1 40 33 79 87 >> > > > > -- > 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 ---- Stephan Klevenz Fabrikstr. 45 69126 Heidelberg Tel.: +49 6221 879625 Fax.: +49 6221 339926
