On Thu, Feb 5, 2009 at 11:41 PM, Clint Savage <herlo1@xxxxxxxxx> wrote: > On Thu, Feb 5, 2009 at 11:23 PM, Basil Mohamed Gohar > <abu_hurayrah@xxxxxxxxxxxxxxxxx> wrote: >> On Thu, 2009-02-05 at 19:55 -0800, Karsten Wade wrote: >>> On Thu, Feb 05, 2009 at 10:33:20PM -0000, Simon Birtwistle wrote: >>> > > Karsten, >>> > > I thought we would be able to use a single instance and have different >>> > > domain names point at different "groups". Have multiple instances to >>> > > do the same thing seems a waste, IMO. >>> >>> IIRC, we discussed this earlier in the process, whether Zikula could >>> handle virtualhosting-like situations. In general, if one monolithing >>> framework can handle the multiple slices and serving of sub-domains, >>> that's fine with me. >>> >>> However, the way I understand our Infrastructure to work, it may not >>> be much more burden to run multiple instances. Puppet is going to >>> manage configurations regardless, etc. >>> >>> > There are a couple of technical issues with single-instance. >>> > >>> > 1. Caching strategies - will certainly be different for the almost entirely >>> > static docs/www subdomains to the more user-oriented docs site. >>> >>> This is true, although I thought we cached by sub-domain so it could >>> do it separately if the Zikula instance were serving different >>> sub-domains. >>> >>> > 2. Zikula doesn't currently support subdomains running on the same set of >>> > files (though it's easily achieved through symlinks) - and would they use >>> > the same database, or a different database? If you use different databases >>> > with the same files then upgrades become a hassle >>> >>> Interesting. For the reasons I say below, I would guess different. >>> >>> > 3. Striping/server separation - e.g. if the magazine / docs / wherever else >>> > are on different physical servers for load or any other reason. >>> >>> IIUC, this is true -- Infrastructure can more effectively scale >>> sub-domains that are unique to the host. >>> >>> > 4. Rolling out new features / fixing problems in general - you don't want a >>> > problem adding a new blogging module on the magazine site to take your www >>> > offline through some freak accident. >>> >>> I'm also not clear if there is an intersect between the two content >>> types. Is there ever going to be a reason to have content migrate >>> from magazine.fp.o to docs.fp.o? Are we going to share processes and >>> workflows? >>> >>> It doesn't seem like it to me right now, although that might be a >>> bridge we want to cross in the future. >>> >>> This comes up similarly for the knowledgebase idea. Is >>> e.g. kbase.fedoraproject.org a separate CMS or a part of docs.fp.o? >>> >>> Since the content types are again different (very short, focused, >>> versioned articles v. longer guides maintained across versions), it's >>> probable that having the kbase and docs CMS in the same instance >>> wouldn't matter. >>> >> >> Are separate domains/subdomains really necessary? Perhaps (and I am not >> sure if Zikula already supports this) we can put "projects" under a URL >> hierarchy rather than individual domains or subdomains. I know that one >> of the slowest things I experience on a daily basis is having to look up >> a new domain or subdomain name. >> > > They are not required, but are a really good idea. It provides > logical separation when thinking about what a particular application > (in this case CMS) does. If we keep the same subdomain for all the > structures, we'd logically separate on uri's. Seems more logical to > me to have it be domains/subdomains as the logical divide. > > Cheers, > > Clint > Man!! I used logical a lot in that sentence, please remove a few for me. :) -- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
