4 Replies Latest reply: Sep 20, 2011 5:07 PM by Lee Hui RSS

    CMIS Support: Debugging

    Robert Frunzke



      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?




        • 1. Re: CMIS Support: Debugging
          Lee Hui Community Member

          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:

          • Win32: C:\Program Files\Common Files\Adobe\CS5ServiceManager\configuration
          • Win64: C:\Program Files (x86)\Common Files\Adobe\CS5ServiceManager\configuration
          • Mac OS X: /Library/Application Support/Adobe/CS5ServiceManager/configuration


          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?

          • 2. Re: CMIS Support: Debugging
            Robert Frunzke Community Member

            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 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).

            • 3. Re: CMIS Support: Debugging
              Robert Frunzke Community Member

              By the way:

              Lee Hui wrote:


              ... rendition issues mostly depend on server's rendition capability.


              Does Adobe Drive support CMIS renditions?

              • 4. Re: CMIS Support: Debugging
                Lee Hui Community Member

                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.