Ya, thats what I was thinking, using an Apache proxy w/ virtual hosts and hit a specific context path (domain), but was just wondering about scalability. Most hardware can handle hosting 80 sites with moderate traffic, but was wondering a bit about the abilities of Sling / JackRabbit.
I guess that is really my solution and the answer to my question. Just have a common set of components / templates (with varied layouts), which is similar to the CQ design... There's only just so many ways you can rearrange a site. Thanks for the discussion. Respectfully, John On Mon, Apr 6, 2009 at 10:16 AM, Pontus Amberg <[email protected]>wrote: > 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 >>>> >>>> >>>> >>> >>> >> >> >> > >
