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 >> > >
