5

CMIS is a protocol supported by all modern Enterprise Content Management servers.

Some legacy clients don't know the CMIS protocol and can only connect to servers via WebDAV (or CIFS, aka Windows shared drive, SMB, Samba, JLAN).

Is there a sort of gateway that would make any CMIS server appear as a WebDAV server?

WebDAV client (for instance Windows Explorer) ----> gateway ----> CMIS server

This would be useful for servers that implement CMIS but not WebDAV/CIFS, for instance NemakiWare.

Note: It is the opposite of this question.

  • Well, Alfresco supports both... Can you not just switch your server? ;) – Gagravarr Aug 15 '14 at 8:50
  • @Gagravarr: I need a portable solution that works with all CMIS servers... that's what interoperability is for :-) – Nicolas Raoul Aug 15 '14 at 9:12
  • 1
    This is more difficult than you think. When you mount a repository as a drive you have to deal with new scenarios. For example, file managers make a lot of redundant requests in a short timeframe. So, either you flood your repository with requests or you build a smart caching layer. You also have to handle short-lived temporary files somehow. Usually, you don't want them in your repository. If your repository supports versioning, then depending on the application and how it handles (temporary) files, it breaks your version history if you don't have a clever detection mechanism. – Florian Müller Aug 15 '14 at 16:52
  • @FlorianMüller: You are very right, there are many tricky points, but on the bright side Alfresco's WebDAV implementation does a great job in our customers' production environments so I hope the same is also possible via CMIS, given enough resources. Your CMIS to WebDAV gateway prototype sounds like an interesting start! If you don't plan to finish it, would it maybe be possible to have the source code? We would put it on Github and fix the bugs for customers. My email: nicolas.raoul at gmail. Thanks a lot for your insight! – Nicolas Raoul Aug 18 '14 at 3:11
  • Maybe this one holds an answer to your question? softwarerecs.stackexchange.com/questions/4218/… – user23795 May 18 '16 at 18:17
-1

Adobe did have a solution:

Adobe Bridge acts as a medium between Alfresco & Adobe InDesign. Adobe Drive 3 allows a connection to a CMIS repository and the ability to mount it as a drive on your machine. This functionality enables you to browse Alfresco as if it were a folder structure on your machine. It also has a powerful search interface which can search content and has a display preview via Adobe Drive and Adobe Bridge. You can perform your own customizable CMIS calls to search for assets and then use the rendition service to display the same within the document library of Alfresco Share Interface.

And Simflofy claims the following:

Simflofy Connectors

In general, here is the mapping between the AtomPub link relations used by CMIS and other specifications:


Appendix A.  Relationship to Java Content Repository (JCR) and WebDAV

   The link relations defined in Section 3 correspond to various
   properties used in WebDAV Versioning [RFC3253] and JCR [JSR-283]:

   version-history

      WebDAV: the resource identified by the DAV:version-history
      property ([RFC3253], Sections 5.2.1 and 5.3.1).

      JCR: the node identified by jcr:versionHistory property
      ([JSR-283], Section 3.13.2.4) for versionable nodes, the parent
      folder for version nodes.

   latest-version

      WebDAV: for version-controlled resources, DAV:checked-in
      ([RFC3253], Section 3.2.1) or DAV:checked-out ([RFC3253], Section
      3.3.1), depending on checkin state.  For version resources, a
      successor version that itself does not have any successors.

      JCR: the version node identified by the jcr:baseVersion property
      ([JSR-283], Section 3.13.2.5) for versionable nodes; for version
      nodes, a successor version that itself does not have any
      successors.

   working-copy

      WebDAV: for version-controlled resources that are checked-out in
      place: the resource itself.  For version resources: each resource
      identified by a member of the DAV:checkout-set property (see
      [RFC3253], Section 3.4.3).

      JCR: for checked-out versionable nodes: the node itself.

   working-copy-of

      WebDAV: the resource identified by the DAV:checked-out property
      (see [RFC3253], Section 3.3.1).

      JCR: for checked-out versionable nodes: the node identified by the
      jcr:baseVersion property ([JSR-283], Section 3.13.12.5).









Brown, et al.                 Informational                     [Page 9]

RFC 5829            Version Navigation Link Relations         April 2010


   predecessor-version

      WebDAV: each resource identified by a member of DAV:predecessor-
      set ([RFC3253], Sections 3.3.2 and 3.4.1).

      JCR: each node identified by a member of jcr:predecessors
      ([JSR-283], Section 3.13.3.3).

   successor-version

      WebDAV: each resource identified by a member of DAV:successor-set
      ([RFC3253], Section 3.4.2).

      JCR: each node identified by a member of jcr:successors
      ([JSR-283], Section 3.13.3.4).

Historically, this should have been part of the specification:

The first thing I'd like to work on is improving the CMIS text that talks about the relation to WebDAV. In its current state it is (IMHO) in the wrong place (I think the comparison should be made with the HTTP binding, not the model), and lacks some precision. In general, although JCR is an API, and WebDAV a wire protocol, both do define a model as well. Sooner or later, people will want to map between CMIS and those, so I think it's inevitable that mappings will be defined — this could be here, in a JSR, in an open-source project like Jackrabbit, or the IETF. I don't think the place matters a lot, as long as it's done properly. It's some time ago that I read the CMIS base spec, but my first impression was that CMIS is a proper subset of the functionality defined in JCR (maybe except query), and defining a mapping CMIS->JCR should be simple. The other way around however will be harder. It seems to me that it would be good to minimize differences where possible. Similarly, WebDAV has large overlap with CMIS, some stuff CMIS doesn't need (like locking), and some stuff missing (type model). On the other hand, WebDAV is extensible, and WebDAV extensions for remoting JCR will be developed anyway. Furthermore, there's some overlap with current discussions on the Atom Protocol mailing list, such as defining extensions for hierarchical collections. It would be cool if we could avoid inventing this for CMIS, if it's already done somewhere else. In this context it would be great to have somebody with GData (Google Data) knowledge in the TC. Also, I expect that Microsoft's AtomPub experts should be involved as well (or are they here already?). Finally, I'd like to understand whether CMIS is mainly thought as a way to connect document stores, or whether we expect it to be used for client (desktop) integration as well. In the latter case it would be good to understand why we're doing something new, instead of extending WebDAV which already has broad client support.

References

  • Nor Adobe Bridge neither Simflofy make the content appear as a WebDAV or CIFS server. – Nicolas Raoul May 25 '18 at 8:02
  • The quote was written someone who was not familiar with CMIS. Saying that it "should have been part of the specification" is inaccurate. And as you know, the CMIS protocol that has finally been approved is totally different from WebDAV. – Nicolas Raoul May 25 '18 at 8:05
  • The writer was Julian Reschke, who knows a thing or two. He also offers the following advice: I think the technically most interesting approach would be to enhance WebDAV to carry the information it currently doesn't have (such as node type information), and then to build CMIS as an extension into the Jackrabbit WebDAV layer. This also shows CMIS mounting as noted – Paul Sweatte May 25 '18 at 14:15
  • The guy is knowledgeable about WebDAV, but the advice you quote was ignored by the CMIS comity, for better or worse. The video above shows a tool that mounts a CMIS folder on a local filesystem: Great (I have personally developed two tools that perform the same), but that is still does not make the CMIS server appear as a WebDAV server. By the way, such tools are bound to lose metadata, because most local filesystems are bad at metadata. – Nicolas Raoul May 28 '18 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.