currently, we are intensively working on a feature-complete CMIS connector for our DAM server.
Adobe Drive seems to be a promising user-friendly client connector for our customers, so it is a primary target client for us.
But, Adobe Drive (even version 3) seems to have some serious restrictions, which are not well-documented, e.g.:
- Versioning is required (the technote reveals this, but lacks details) - am I right in assuming that AD will not (never) support a workflow based on auto-versioning (where the repository itself cares about creating new versions on changes)? Currently it seems to fully rely on a checkout+checkin scheme, based on the mediocre CMIS "private working copy" concept, which will produce very frustrating user experiences in the long run... (think about stale locked files, users troublings admins to unlock, ...)
- AD uses the cmis:name property for path segments - will AD 3.x or 4.0 fix this issue?
- Renditions, you know...
I think, the issues are primarily due to a complex and vague CMIS specification. Don't get me wrong, I think CMIS is a huge step in the right direction, but the specification is abysmal - over-designed on one end, and a text full of errors on the other end. But still, it is a good thing to have an interoperability standard after all. But with the current CMIS standard it seems to be impossible to code "for the standard", because there is so much ambiguity, and because of this, all currently circulating clients have its issues, including AD3. Bad start for a standard, but I still have hopes.
Disregarding all the issues, our biggest problem is, that we can not comprehend the inner workings of Adobe Drive. Stack traces in the protocol just give us a sketchy view on what could have happened, after something bad happened. But everything else feels like reverse-engineering, at least like trial & error development.
For example: Which <link> elements (and so, which resources) does AD actually use to navigate in the repository, when and why will it call getObjectParents, getObject, getAllowableActions, getObjectByPath, which attributes of some xml does it use for what purpose, and so on, and so on, ...
For example, with the current dev version of our CMIS implementation, AD3 initiates an elusive barrage of requests for any simple reading action. After intensive validation, we can say, that the server responses are totally standards compliant. It is impossible to understand why AD does that.
In short: Is there a debugging mode in AD? If so, how can it be enabled?