Thanks for the feedback, Eric.

Wouldn't sharing an application name cause some
sharing of variables between sites?

And: So using ?reinit=1 or something similar resets
variables within *every* application, even with different
application names?

I thought the main reason for using different application
names was to prevent application, session, etc variable bleed-over and
to allow reinitializing of one application without affecting
others, even on the same codebase.

???



-----Original Message-----
From: Eric Cobb [mailto:cft...@ecartech.com] 
Sent: Friday, February 18, 2011 9:15 AM
To: cf-talk
Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC)


One thing you may want to take into consideration, if you plan on having 
many sites run through this codebase, is NOT giving each site a unique 
application name.  (as in <cfset this.name = "#cgi.server_name#">).   I 
once worked on a MSOC system that ran somewhere around 2700 websites, 
and each site had its own application name.  So, every time we cached a 
CFC in the application scope, we had 2700 separate instances of it, even 
though they were all identical.  We had 2700 "application.dsn" variables 
stored in memory, even though they were all identical.  We had multiple 
CF servers each trying to store and manage the same 2700 separate 
applications, all of which were completely identical.  And the worst 
part was, there was no passing "?reinit=1" if we made code changes and 
needed to reset the application scope, we had to restart each CF server 
and take all 2700 sites offline in order to reset all of the 
applications.  To me, this always seemed inefficient, and a gross waste 
of CF processes and memory.

Just some thoughts I wanted to throw out there.  Definitely something to 
think about if you're planning on having a large number of sites on your 
system.

Thanks,

Eric Cobb
ECAR Technologies, LLC
http://www.ecartech.com
http://www.cfgears.com


On 2/17/2011 8:59 PM, Rick Faircloth wrote:
> Your approach at Broadchoice sounds exactly like what I'm
> anticipating implementing...
>
>
> -----Original Message-----
> From: Sean Corfield [mailto:seancorfi...@gmail.com]
> Sent: Thursday, February 17, 2011 5:58 PM
> To: cf-talk
> Subject: Re: Feedback on this approach to "many sites, one codebase"
(MSOC)
>
>
> On Thu, Feb 17, 2011 at 10:21 AM, Robert Harrison
> <rob...@austin-williams.com>  wrote:
>>   1.  Your relationship with the client changes and the client wants to
> take the site and move. Now you are faced with either holding the client's
> site hostage or giving away your multi-site base code framework (possibly
> even to a competitor). Neither of those is an attractive option.
>
> It really depends on how you set up the contract and the expectations.
> Broadchoice (where I worked in 2008) has a software-as-a-service CMS
> which hosts a number of high-profile client sites. It's very clear to
> the clients that they're using a multi-tenant SaaS platform and
> therefore they know upfront that this isn't a site they can just "take
> over" (although there is an option to license the codebase for an
> internal installation).
>
>> 2. Also, assume one or more clients keeps coming back to you to make
> adjustments and additions.  Now your code is getting more and more mucked
up
> with custom-code exceptions.  That's also not cool. Eventually that will
> make your framework really difficult to manage and upgrade.
>
> At Broadchoice we tackled this by designing a pluggable, modular
> architecture for "applications" that could literally be dropped into
> the (single) codebase and then configured to be available on any
> client sites. The nice thing about this is that one client may pay for
> the module to be developed but it's still provided to them as a
> service - they're not purchasing the code - and then it can be offered
> to other clients, as a paid option if appropriate.
>
> The key is really in deciding whether you're "just" hosting a number
> of sites or whether you're offering a "website platform" in a SaaS
> model.
>
> You might also want to read Steve "Cutter" Blades blog series about MSOC:
>
> http://blog.cutterscrossing.com/index.cfm/MSOC
>
> At World Singles, we have about 50 sites all running on a single
> codebase. Mostly the sites differ in branding and look'n'feel but
> there are functional differences between many of the sites, managed
> with a similar model to what we used at Broadchoice.
>
>
> 



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342428
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm

Reply via email to