chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Huebel, Jens" <j.hue...@sap.com>
Subject Re: Proposed change TypeManager
Date Tue, 10 Sep 2013 08:21:37 GMT
The idea of this interface was to have one instance of an implementation
per repository. So the repository id would then be a parameter for
creating the instance. Changing this and add a repository id per method
would introduce a much bigger incompatibility.

What we at at least can do is improve the documentation what methods are
needed for query. I still feel that one interface is a simpler approach.

Jens


On 26.08.13 12:02, "Michael Brackx" <michael.javaone+cmis@gmail.com> wrote:

>Hi,
>
>I was about to suggest the opposite: to drop the unused methods from that
>interface.
>It feels wrong to have to implement this complete interface to use the
>query support. Only recently did I discover that I had some unused code
>because of this.
>Maybe we can have 2 interfaces. One minimal to use with the query support
>and one full with the currently unused methods and your new proposed
>methods.
>
>In general this interface is not that useful to me, as it is for one
>repository only. An extra repositoryId parameter for all methods would
>improve that.
>
>Michael
>
>On Fri, Aug 23, 2013 at 7:49 AM, Huebel, Jens <j.huebel@sap.com> wrote:
>
>> Hi all,
>>
>> in the server-support package we have an interface TypeManager that is
>> used by the query parser to get access to the CMIS type definitions.
>>With
>> CMIS 1.1 we have added type mutability. The InMemory server therefore
>>has
>> added an interface extension like this:
>>
>>
>> public interface TypeManagerCreatable extends TypeManager {
>>
>>     void addTypeDefinition(TypeDefinition typeDefinition, boolean
>> addInheritedProperties);
>>
>>
>>
>>     void updateTypeDefinition(TypeDefinition typeDefinition);
>>
>>
>>     void deleteTypeDefinition(String typeId);
>>
>> }
>>
>> I guess that many server implementations do something similar and wonder
>> if we should add these methods to the TypeManager interface. Serves not
>> implementing type mutability simply can throw an exception. Of course
>>these
>> methods are not needed by the query parser. But from my perspective
>> TypeManager is a more generic interface and it seems simpler and
>>cleaner to
>> add type mutability there.
>>
>> Any thoughts? If no one objects I will add these methods with the 1.0
>> release.
>>
>> Jens
>>


Mime
View raw message