incubator-chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Klevenz, Stephan" <stephan.klev...@sap.com>
Subject RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation
Date Wed, 12 May 2010 15:35:18 GMT
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

Mime
View raw message