Re: CMS + Fedora Magazine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux