Hi, Sorry for the delay ....
Am Donnerstag, den 22.11.2007, 13:36 +0200 schrieb Jukka Zitting: > How does this compare to using JCR adapters for things like URLs and > local files? What adapters ? The IO handlers of Jackrabbit simple WebDAV ? I don't see others. Anyway, such adapters tend to be unconnected and distributed and are not generally transparent to use. In contrast to the Resource, which has a unified and very simple interface upfront with mixin providers (you may call it adapters, see my last mail on this thread). This concentrates all work of providing different views in one place and prevents implementing the same thing over and over again. > To me it seems like the Resource interface, as currently > envisioned, might well end up growing to a mini-Node abstraction by > time. The Resource interface will never be a mini-Node abstraction. By no means. It is meant as a simple and singular representation of a resource upon which Sling and microsling operate. The scripts and servlets may after that look under the hood of the Resource and use whatever additional data, the Resource may be able to provide. > I find it odd that the default URI resolver first uses JCR to look up > a node to be wrapped into a Resource instance that'll then be > unwrapped using type casts by servlet/script components that do need > direct JCR access. In general I think that any APIs that require type > casting as a central feature are somewhat broken. Not necessairily. I agree with respect to the former getRawData method, which involves quite some magic to find and use the correct type. This has probably not been the best of all solutions. > > Also, I feel that the object mapping would be better handled on top of > the resource API, not as a part of it. Especially since it implies two > completely separate node type mappings (one for the servlet/script > resolution, one for object mapping) within Sling. Yes and no. If we implement it inside the resource, we abstract it away from the user and place the burden on a single location. > The same goes for the StreamProvider idea. As soon as you start > thinking that you'd need separate stream representations for nt:file > and nt:unstructured nodes, you end up with yet another indepent node > type mapping within the framework. I'm sure that this can only cause > confusion later on. Right, I agree, that if we have the object mapping in the Resource support, we should also have the stream access there. I consider basing such an implementation on the IOHandlers framework of the Jackrabbit simple WebDAV. Regards Felix
