Hi, On Nov 22, 2007 11:13 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > After seeing a general consensus, I created a JIRA for this [1]. In > addition to the initial proposal on the list I added another one. While > the first one is certainly straight forward, the second one has the > added benefit, that the XXXProvider interfaces may also be used in other > circumstances than just the Resource use case.
How does this compare to using JCR adapters for things like URLs and local files? To me it seems like the Resource interface, as currently envisioned, might well end up growing to a mini-Node abstraction by time. 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. 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. 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. BR, Jukka Zitting
