chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <fmuel...@opentext.com>
Subject RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation
Date Wed, 19 May 2010 07:37:26 GMT
Go ahead. We should solve those general stuff as soon as possible.

Florian

-----Original Message-----
From: Stephan Klevenz [mailto:stephan@klaeff.de] 
Sent: Mittwoch, 19. Mai 2010 08:37
To: chemistry-dev@incubator.apache.org
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:stephan.klevenz@sap.com] 
> 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

> 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:fmueller@opentext.com] 
> 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 
> 
> PropertyType getPropertyType();
> 
> to the PropertyData interface. 
> 
> 
> Florian
> 
> -----Original Message-----
> From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com] 
> 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>? 
> 
> Regards,
> Stephan
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Florian Müller [mailto:fmueller@opentext.com] 
> 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. 
> 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:stephan.klevenz@sap.com] 
> 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üller [mailto:fmueller@opentext.com] 
> 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. 
> 
> Florian
> 
> -----Original Message-----
> From: Florent Guillaume [mailto:fg@nuxeo.com] 
> 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 <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:
>>    <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 <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ü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






Mime
View raw message