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" <[email protected]> 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 <[email protected]> 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 >>
