Hi Ian, I could imagine two approaches to your problem:
(1) Register a resource provider for the root node of your "hashed" tree. When asked for a resource, it will apply the mapping function to find the actual resource. (2) Employ the dynamic URL Rewriting patch you proposed in SLING-986: You attach that rewriter such that it resoloves and maps as required. The advantage of the second approach is, that you have a "free" two-way mapping for resolving URLs (incoming) and mapping resource paths to URLs (outgoing). The disadvantage of both approaches is, that it is actually configuration and a simple resource creation à-la curl -F"sling:resourceType:sakai/store" http://localhost:8080/bigstore might not be enough and you would have some additional functionality (a listener maybe) to set this up on demand. Regards Felix Ian Boston schrieb: > > On 2 Jun 2009, at 16:09, Paul Noden wrote: > >> Hi Ian, >> >> 2009/6/2 Ian Boston <i...@tfd.co.uk> >> >>> AFAICT its impossible to virtualize paths (URI wrt JCR path) using this >>> approach in the JCR. >>> >>> Unfortunately for me, its a use case I can't ignore as we have lots of >>> situations where a non listable could contain millions of items. >>> Back to square one. >>> >>> >>>>> The current design and intention is, that for any one (root) path >>>>> there >>>>> may only be one resource provider registered. So for example, for a >>>>> (root) path "/some/path", there may only one. Of course there may be >>>>> another one at "/some" or at "/some/path/below". >>>>> >>>>> I want to be able to bind a special Resource to a node with a >>>> corresponding resourceType (created by the application) anywhere in the >>>> content system, so that all the standard Sling processing can access >>>> that >>>> Resource. >>>> >>>> For example: >>>> I want to be able to create a node anywhere in the content system, and >>>> under that node have a hashed store that is managed as if the >>>> entire node >>>> space was flattened. >>>> >>>> eg >>>> the URL >>>> /x/y/z/store/12312312/a/b/c >>>> is mapped to JCR space >>>> /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c >>>> >>>> using the ResourceProducer mechanism. >>>> >>> >> Can you go into some more detail regarding the requirements for this >> strategy? > > Paul, > > Sure, > I need to create stores of potentially a large number of items single > locations in URL space where the items can be > accessed by a URL > reference each other. > be listed by paged search. > > The main requirement is that the collection should be addressable with > the following form > /x/y/z/1001 > > The path might extend further eg > /x/y/z/1001/d/e/f > > the cannonical form being > /x/y/z/n/** > where n is one of a set of a large number of items (eg 10M) > > AFAIK, to make this work JCR n needs to be expanded to a hashed tree eg > /x/y/z/aa/bb/cc/dd/n/** > > Having performed the hashing, I would ideally like to reuse the > SlingPostServlet and related functionality, so that > > curl -F"sling:resourceType:sakai/store" http://localhost:8080/bigstore > > creates a store (identified by the sakai/store resourceType) > > curl -F"status:stage1" http://localhost:8080/bigstore.create.html > > a redirect coming back to (ad23415g4 is an opaque token) > http://localhost:8080/bigstore/ad23415g4 > > Which can then be used in further operations on that item. > > >> >> >> Could you use node representations in store to placehold/redirect to the >> nested content at "content/aa/bb/cc/dd/"? > > Provided that HTTP would never see content/aa/bb/cc/dd/, but I guess by > redirect, you mean http redirect, in which case, no since relative URL's > break at this point. > eg ../ad23415g4/related_information.html > > >> >> >> Regards, >> >> Paul Noden > >
