Hi Jonathan Jonathan Cook schrieb: > Felix, > > I will take a stab at this, I hope you don't mind since I am not using > the functionality described, I may be completely off the mark.
I certainly don't mind and it does not really matter whether you are off the mark or not -- you add your own POV which may as well be helpful. So, you are definitely welcome to comment. > > Can FsResourceProvider work w/o the superType "/sling/fs/resource"? The FsResourceProvider does not care for the actual resource and resource super type. It just provides the resources with the respective types. So, yes, it can work. > Can > it use "nt:file" to encompass files and folders? That's what I am proposing: use nt:file as the resource type for files and nt:folder for directories (aka folders) > It would be strange to > have a superType that was defined in a different way from the resource > type, so mingling stuff with an interface defined in JCR with stuff with > an interface defined in Fs would not be that coherent. What interface ? JCR does have node types and Sling does have resource types. The only connection between the two is, that Sling uses the node's primary node type as the resource type if there is no sling:resourceType property. Thus for a plain nt:file node, Sling will use the nt:file node type as the resouce type. Same for a plain nt:folder node. > > If it can't or you don't want it to, it seems like the question may > become whether JCR should expose some other type which underlies nt:file > and nt:folder through the getSuperType() method, in order to provide a > common interface for querying file and folder nodes (perhaps looking at > date modified, last access, etc?). > > From a practical standpoint it makes sense to have a "resource type" in > JCR, but I don't know what the implication would be as far as the spec > and the existing contracts around using getSuperType, or whether this > kind of interface can effectively live in a layer above JCR to make an > end-run around the question. Resource types are a Sling concept related to the Sling concept of Resources and the Resource tree, which is a simplified abstraction of the underlying data structures. There are a lot of simplifcations possible with the Resource abstraction: We can mix real JCR content with "virtual" servlets and provide uniform access, thus making the servlet/script resolution as we have it possible in the first place. It also allows mixing content from bundles and the filesystem into the resource tree also providing uniform access. Thus, for example the servlet resolver does not know whether a servlet it has resolved is a script in the repository or from a bundle or from the filesystem or actaully is just a servlet service registered in the OSGi service registry. The servlet resolver does not care, either, since all it wants is a servlet whose service method can be called. Regards Felix > > Regards, > J5 > > Felix Meschberger wrote: >> Hi, >> >> We currently have the following resource providers which handle resource >> types for resources denoting files and folders: >> >> (1) JcrResourceProvider: >> File has resource type nt:file >> Folder has resource type nt:folder >> Jcr[Node|Property]Resource.getSuperType() returns null >> >> (2) BundleResourceProvider: >> File has resource type nt:file >> Folder has resource type nt:folder >> BundleResource.getSuperType() returns null >> >> (3) FsResourceProvider: >> File has resource type sling/fs/file >> Folder has resource type sling/fs/folder >> FsResource.getSupertType() returns sling/fs/resource >> >> I have the impression, that in the context abstract resource access, we >> might want to have common resource types identifying resources denoting >> file and folder concepts. >> >> So, I think the FsResourceProvider should be modified to implement the >> resource type assignment used by the BundleResourceProvider and the >> JcrResourceprovider. >> >> WDYT ? >> >> I am ready to do a 1.0 release of the FS Resource Provider once this has >> been resolved. >> >> Regards >> Felix >> >> > >
