Hi, I have no issue requiring this change. However, over some time, several things lead me to think that this would be a good thing to change.
Some thoughts: - A major version bump is an ideal moment to make breaking changes. - Actually adapting to the changes might not be that much work. For example for the create methods, server implementations would need to wrap the string in an object. Clients would need to call getId. For methods now returning void, servers could just return null. There have been other breaking changes in the past. - The webservices binding is not recommended as it is not performant. Also it is being deprecated in future versions of the spec. - There is no easy way to send "extensions" (e.g. per request http query params) for atompub/browser binding. Changing the CmisService might accommodate that. - The TCK should also be able to test responses from servers that do not use chemistry. Also, getObject might indeed return different results, depending on the timing. For example due to transactions or db/backend calculated fields. I actually encountered an issue with server responses in practice, that was not detectable with the java client. - Always doing an extra call client side to get the object details may hurt performance. The webservices binding is holding the others back here. That the extra data is optional, should just mean the extra call is optional. If the server returns what is needed, that should be enough. I do also have a concrete issue, but will make a separate proposal for it requiring less changes. Michael On Tue, Aug 23, 2016 at 2:22 PM, Florian Müller <f...@apache.org> wrote: > Hi Michael, > > Changing this interface is rather difficult. It is composed of other > interfaces that are the core interfaces for the client and server > implementations. Changing the interfaces would break a lot in the OpenCMIS > code and would break applications currently using these interfaces. > > What we could do is introducing a new additional low-level interface for > the Browser binding (and the AtomPub binding), which contains the methods > in question with a slightly different name and a new return data type. > > On the client side, you would then have the choice of calling the old or > the new method. On the server side, the OpenCMIS code could check if the > new interface is implemented and if so, calls the new instead of the old > method. > > But that's a lot of work. Could you explain your problem with the current > approach? > > I understand that testing with the TCK is restricted - but not really. The > OpenCMIS server calls getObject after it created the object and testing > getObject is possible with the TCK. This is only an issue if the server > returns different data when getObject is called twice for the same object. > On the client side, you may save one getObject call after a create call - > but not reliably. Servers may not return all data. They are only forced to > return the cmis:objectId property. Everything else is voluntary and beyond > the control of the client. To be save, the client must call getObject. > > From a generic client of view, I don't see much value in introducing this > new interface. > > - Florian > > > > Hi, >> >> Can the CmisService interface be changed to be more in line with the >> browser binding? >> >> For example, the create methods could return ObjectData instead of String. >> Or, alternatively, they could return an ObjectId and the server >> implementation can choose to return only an id or a full object; similar >> to >> what was done with PropertyDataWithDefinition. >> >> In general the service methods could return all the needed information to >> construct the browser binding response. >> >> This could also help solve the client side issue that the java client >> cannot access the response from services, and thus that they cannot be >> tested (e.g. in the TCK). >> >> Michael >> >
