5 Replies Latest reply on Mar 29, 2010 11:58 AM by rhauch

    ModeShape and WebDAV

    bcarothers

      I'm looking at fixing MODE-281 (Support accessing repository through WebDAV).  There are a couple of design decisions that I'd appreciate feedback on.

       

      1.  Common web code location - The 'Shape WebDAV servlet would be able to reuse some of the code in the REST server package (e.g., ModeShapeJcrProvider, ServletSecurityContext, maybe a few others). but I don't know that I should set up a dependency from the WebDAV module to the REST server module.  Alternatively, I could just split out a common web module that contains these classes, and have the REST and WebDAV modules depend on the common module.  Or I could just add the WebDAV classes into the REST server package and rename it.  They'd add very little code and few dependencies.

       

      2.  Workspaces/Repositories - The REST server has a fairly natural way of specifying the repository and workspace in the URL.  Is this practice worth repeating in the WebDAV servlet, or should the WebDAV servlet only support a preconfigured repository/workspace pair?

       

      Thanks in advance for any feedback!

        • 1. Re: ModeShape and WebDAV
          rhauch

          1.  Common web code location - The 'Shape WebDAV servlet would be able to reuse some of the code in the REST server package (e.g., ModeShapeJcrProvider, ServletSecurityContext, maybe a few others). but I don't know that I should set up a dependency from the WebDAV module to the REST server module.  Alternatively, I could just split out a common web module that contains these classes, and have the REST and WebDAV modules depend on the common module.  Or I could just add the WebDAV classes into the REST server package and rename it.  They'd add very little code and few dependencies.

          My gut reaction is to create a new 'modeshape-web-jcr' project and move all of the generic stuff into that. I can envision this not only being use for our WebDAV and REST server modules, but also useful for users when they're building their own web apps on top of JCR and ModeShape.

           

          The REST server module can remain in 'modeshape-web-jcr-rest', and the WebDAV module can live in a new 'modeshape-web-jcr-webdav' project, and both can depend on 'modeshape-web-jcr'.  This approach is also scalable, if we want to add other kinds of web modules.

           

          2.  Workspaces/Repositories - The REST server has a fairly natural way of specifying the repository and workspace in the URL.  Is this practice worth repeating in the WebDAV servlet, or should the WebDAV servlet only support a preconfigured repository/workspace pair?

           

          One question I have with the WebDAV servlet is whether or how it can expose content that isn't made of only files and folders (e.g., nodes that have a primary type of "nt:file" or "nt:folder").  This is more likely at the top levels of the repository, which may be "nt:unstructured" or even other types of nodes, under which there are areas for files and folders.  Are the non-file/folder nodes treated as pseudo-folders, and if so how does it know not to expose the subgraphs that contain no file or folder nodes?

           

          This leads me to wonder whether it would be better for the WebDAV servlet to be configured to expose certain subgraphs, perhaps something along the lines of "mount points" in the repository. In other words, the WebDAV servlet might expose repository/workspace/area, where "area" is almost like a symlink to a single file or folder node (or something analogous to a mount point).  (Perhaps the target of the symlink wouldn't have to be an nt:file or nt:folder, as the "area" node is the folder representation of it.)  These symlinks/mountpoints could be regular nodes of some new node type (e.g., "mode:symlink" or "mode:mount") stored directly under the root or, if that's "too invasive", in the "/jcr:system" branch.

           

          WDYT? How far off-base am I? :-)

          • 2. Re: ModeShape and WebDAV
            bcarothers

            Randall Hauch wrote:

            My gut reaction is to create a new 'modeshape-web-jcr' project and move all of the generic stuff into that. I can envision this not only being use for our WebDAV and REST server modules, but also useful for users when they're building their own web apps on top of JCR and ModeShape.

            The more I think about it, the better this approach sounds.  Will do.

             

            One question I have with the WebDAV servlet is whether or how it can expose content that isn't made of only files and folders (e.g., nodes that have a primary type of "nt:file" or "nt:folder").  This is more likely at the top levels of the repository, which may be "nt:unstructured" or even other types of nodes, under which there are areas for files and folders.  Are the non-file/folder nodes treated as pseudo-folders, and if so how does it know not to expose the subgraphs that contain no file or folder nodes?

            I was planning on using the same heuristic that we talked about for a "files" REST view.  Namely, nodes with primary type nt:file will be exposed through WebDAV as files.  Everything else will be returned as a WebDAV folder.  I haven't quite started testing this approach yet, but it should work.

            This leads me to wonder whether it would be better for the WebDAV servlet to be configured to expose certain subgraphs, perhaps something along the lines of "mount points" in the repository. In other words, the WebDAV servlet might expose repository/workspace/area, where "area" is almost like a symlink to a single file or folder node (or something analogous to a mount point).  (Perhaps the target of the symlink wouldn't have to be an nt:file or nt:folder, as the "area" node is the folder representation of it.)  These symlinks/mountpoints could be regular nodes of some new node type (e.g., "mode:symlink" or "mode:mount") stored directly under the root or, if that's "too invasive", in the "/jcr:system" branch.

            Let me mull that one over.  On the one hand, I think that would be more complicated to code and, more importantly, to configure.  It would be very powerful though.  I'd welcome opinions from others on this as well.

            WDYT? How far off-base am I? :-)

            Not very, if at all ;-)

            • 3. Re: ModeShape and WebDAV
              rhauch

              I do agree that starting with the simpler approach is far better and easier.

               

              However, one potential gotcha is that if the WebDAV module treats all non-file nodes as WebDAV folders, then will these folders need to be read-only? If not, couldn't a client attempt to modify a WebDAV folder (that was really, say, an "nt:unstructured") by creating a child folder? That will likely not make sense under most non-file or non-folder nodes.

               

              Another "usability" issue with having the WebDAV module expose all nodes (albeit all but the "nt:file" nodes as WebDAV folders) is that literally all content is visible through WebDAV, and this might actually make it much harder for WebDAV clients (and users using these client applications) to navigate to the real areas they should be using. I would expect it'd be pretty nice to have more control over what parts of the repository are exposed by a WebDAV server.

               

              Brian Carothers wrote:

              Let me mull that one over.  On the one hand, I think that would be more complicated to code and, more importantly, to configure.  It would be very powerful though.  I'd welcome opinions from others on this as well.

               

              It might not be too complicated: It'd basically require a transformation between the WebDAV URL (or resource path) and the JCR path. Basically, take whatever is in the URL after the mount point name and append it to the mount point's equivalent JCR path. To transform from the JCR path to a URL, simply do the reverse.  And if each mount point is defined as a node in the repository, the only configuration is creating the mount point nodes (which would have the corresponding path as a property).

               

              I'm trying to think whether federation gives us a way to have this control. You'd have to create a new federated repository that represented the WebDAV-accessible content, but all kinds of different areas can be projected into this "WebDAV repository". The downside is that it requires establishing a new federated repository for each WebDAV server cluster.

              • 4. Re: ModeShape and WebDAV
                bcarothers

                Randall Hauch wrote:

                 

                However, one potential gotcha is that if the WebDAV module treats all non-file nodes as WebDAV folders, then will these folders need to be read-only? If not, couldn't a client attempt to modify a WebDAV folder (that was really, say, an "nt:unstructured") by creating a child folder?

                I'm not sure I follow that line of reasoning, but I don't believe that there is an issue here.  Non-file nodes are exposed through WebDAV as folders, but their primary type isn't changed.  If a client attempted to rename a folder through WebDAV, they could potentially modify the primary types though, as WebDAV "renames" seem to be implemented as a WebDAV delete followed by a WebDAV add.  Adding new children won't modify the parents though.

                Another "usability" issue with having the WebDAV module expose all nodes (albeit all but the "nt:file" nodes as WebDAV folders) is that literally all content is visible through WebDAV

                Are you suggesting a primary type-based filter?  I think that would be nice.  I'd be happy to add that.

                It might not be too complicated [to implement mount points]

                I agree that the concept is simple.   The patch that I just uploaded doesn't provide this feature, but it does provide an extension point (RequestResolver/UriResolver) that could be used to provide arbitrarily complex projections from the repository space into the WebDAV URI space.

                I'm trying to think whether federation gives us a way to have this control. You'd have to create a new federated repository that represented the WebDAV-accessible content, but all kinds of different areas can be projected into this "WebDAV repository". The downside is that it requires establishing a new federated repository for each WebDAV server cluster.

                It would do this, but I think it would be simpler to write a customer RequestResolver once and avoid having to continually manage "extra" federated views of the same underlying datastores.

                • 5. Re: ModeShape and WebDAV
                  rhauch

                  I think what you've done in the patch is great. It's nice and simple, but offers a lot of flexibility now and in the future.