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?
Thank you very much for using Adobe Drive.
Usually, to debug a connector, you can follow 'Getting Started' -> 'Step 1: Setting up the Eclipse development environment' section in Adobe Drive SDK document. Adobe Drive SDK download page: http://www.adobe.com/devnet/adobedrive/eula-3.html. But currently, CMIS connector doesn't open its source code. I think log may provide some info to you. To configure log level, you need to edit log4j.xml in the following folder:
Adobe Drive currently rely on checkin + checkout scheme, and rendition issues mostly depend on server's rendition capability. For your mentioned issue 'AD uses the cmis:name property for path segments', could you explain it in detail?
Thank you, I will try the log settings and the SDK with eclipse.
About "AD uses the cmis:name property for path segments":
CMIS has a concept called "path segments". Those path segments contain the file or directory names that clients should use. But AD uses the "cmis:name" property, instead of those path segments.
The CMIS v1 spec (section 18.104.22.168) says, that "repositories might choose to use cmis:name or content stream filename for pathSegment token".
Note: the repository has the decision, not the client. The client is not allowed to choose cmis:name over path segments. Clients have to use path segments.
This is a problem whenever a repository allows files with the same name in the same folder (not uncommon, because repositories use internal ids), or when the repository does not use cmis:name for filenames at all (but for e.g. titles).
CMIS connector in Adobe Drive doesn't support rendition as it doesn't implement related logic(hint: IGetAssetHandler for Icon data, and IGetPreviewHandler), but for customized connector, if it implements rendition related handlers and server supports rendition, then user can view thumbnail and preview in Bridge. One example is connector for ADEP services in Adobe Drive. It can show thumbnail and preview.