That's a great idea Felix and is definitely not off topic. Thank you! On Mon, Apr 6, 2009 at 12:36 PM, Felix Meschberger <[email protected]>wrote:
> Hi, > > While probably similarly off-topic, I have just written down another > idea in this area: support for multitenancy [1]. The idea is, that at > the beginning of a request, based on various request input (URL, > authenticated user, etc.) a Tenant might be selected for the request, > which may then influence how the request will be handled. > > One such influence would be ResourceResolver.getSearchPath() depending > on the the actual Tenant. Others are conceivable and possible by just > declaring a Tenant to provide a set of key-value pairs. > > Regards > Felix > > [1] http://cwiki.apache.org/SLING/multitenancy-support.html > > Pontus Amberg schrieb: > > This is not really a reply to your question but I just wanted to mention > > that I think that it is possible to map specific parts of the content > > tree to specific domains/sites [1] . Haven't tested it myself but it > > looks pretty cool. > > > > /Pontus > > > > [1] https://issues.apache.org/jira/browse/SLING-249 > > > > John Crawford wrote: > >> Also, what about if I want to host many sites? I can see clustering the > >> sites together by template. So if Brands A,B and C want a specific > >> layout > >> or set of components, give them server running on 8081. Perhaps > >> Brands D, E > >> and F want a completely different layout / set of components, give them > >> server 8082. All sites could on the same repository just as easily (and > >> probably easier), but I could see it getting out of hand with 80+ sites. > >> > >> I guess my question is one of scalability. Is it recommended to have > >> more > >> than say ten sites on one instance? And is it better to only have one > >> instance / physical hardware? > >> > >> Respectfully, > >> John > >> > >> > >> On Mon, Apr 6, 2009 at 8:46 AM, John Crawford <[email protected]> > wrote: > >> > >> > >>> Hi Bertrand, > >>> > >>> Thank you for the reply, it definitely makes sense. > >>> > >>> The separation was primarily for 1) the main website 2) an > >>> administrative > >>> type of area and then 3) a clients section where they can place > >>> orders and > >>> have access to their private data (transaction handled by application > >>> server). The admin area almost doesn't even need to have a backing > >>> repository (except for the fact that it's gated -- security). I > >>> would just > >>> rely on the post servlet to handle my writing and the json servlet to > >>> gather > >>> the data. Another thing, in production, I would want to restrict the > >>> post > >>> servlet to only the requests made inside of my network (in your > >>> experience, > >>> do you find this to be the best solution to protecting the data on > >>> live?). > >>> I could definitely see it being in one repository, just different > >>> content > >>> paths, but thought having separate instances might help with > >>> performance/modularity (please correct me if I'm wrong). > >>> > >>> In one of David Neuschler's blog entries or articles (I believe thats > >>> the > >>> source), I read that workspaces were more for replicas/copies of data > >>> (such > >>> as an author/publish environment), but I have had some thoughts about > >>> separating domain content in there as well (but haven't due to David's > >>> posts). I guess he primarily wants to eliminate as much overhead as > >>> possible, so perhaps thats the reason for his statement and it seemed > to > >>> align with your suggestions below as well. > >>> > >>> Thank you again. > >>> > >>> Respectfully, > >>> John > >>> > >>> > >>> On Mon, Apr 6, 2009 at 7:37 AM, Bertrand Delacretaz < > >>> [email protected]> wrote: > >>> > >>> > >>>> Hi John, > >>>> > >>>> On Mon, Apr 6, 2009 at 4:09 AM, John Crawford <[email protected]> > >>>> wrote: > >>>> > >>>>> I'm in the process of implementing a site that is basically > >>>>> comprised of > >>>>> three independent modules, however, I want them to interact on some > >>>>> > >>>> level.... > >>>> > >>>> > >>>>> ...I'm trying to decide if it's best practice to have one repository > >>>>> > >>>> with 3 > >>>> > >>>>> different workspaces (which will need to interact) or if it's > >>>>> better to > >>>>> > >>>> have > >>>> > >>>>> multiple repos with different RMI ports (thus, non-standard). > >>>>> > >>>> Eventually, I > >>>> > >>>>> may have these on separate machines, but certainly no need at this > >>>>> > >>>> time.... > >>>> > >>>> I'd start by even questioning the need for separate workspaces...the > >>>> content of your three modules might simply be under separate paths in > >>>> a single repository, and you can use sling resource types to > >>>> differentiate between them. > >>>> > >>>> Next step, if you really need it, might be to have each module in its > >>>> own workspace. This would require less coordination between the teams > >>>> designing each module, and might make it easier to manage strict > >>>> separation of access rights, but apart from that I'm not sure what the > >>>> advantages are. > >>>> > >>>> Interaction between the modules can be much easier with a single > >>>> workspace. Using JCR observation on repository subtrees works quite > >>>> well for inter-module communications. > >>>> > >>>> I don't usually see a need at the application level for separate > >>>> repositories, the need might come from environment / admin / security > >>>> requirements, but if you can avoid that it's probably easier. > >>>> > >>>> > >>>>> ...Also, is there any other gotchas or good practices I should > >>>>> follow in > >>>>> > >>>> this > >>>> > >>>>> area during my implementation?... > >>>>> > >>>> Not sure what you mean by "this area", but the choice of a single or > >>>> multiple workspaces will have a big impact on your code. > >>>> > >>>> Hope this helps, and if not feel free to ask, maybe with a bit more > >>>> details about your requirements. > >>>> > >>>> -Bertrand > >>>> > >>>> > >>> > >> > >> > > > > >
