I recently was confronted with an unexpected event:
The method CMSObject.getVersions() of the PTC Server adapter did not deliver the expected versions of the CMSObject but an error message :"Method not implemented".
From a project managers point of view this is a very bad situation:
Learning about unimplemented features only from error messages (“Not implemented”) while implementing customizations is far too late and leads to the impression that documented features cannot be regarded available until tested.
I do planning based on API documentation.
I actually would expect that described features of the documentation are generally available if there is no hint about being not.
The uncertainty of implemented/not implemented methods (or let’s say features) makes it impossible to keep projects time schedules.
Realistic planning software development / customization is not possible from this basis. Customization projects depend on a actual and true API documentation. Actually it takes a lot of time to re-convince software developers to continue working with the documentation / actual state of the AOM packages after such "surprises".
I would recommend urgently to work on the Adapter Limitations online help page and the Javadoc pages to mentions adapter specific implementations / limitations ( including missing implementations). The pure interface documentation show currently "only" the potential of some implementations.
By the way I would expect the PTC Server Adapter to be the reference implementation (and customers best choice) for the interfaces of the AOM packages rather than the weakest implementation.