Re: [binarycloud-dev] BC Serious Concerns, Production Standpoint

[Alex B. <en...@tu...>]

have a look at my response :)

> Hey - I've got some things to say about this topic. What you've described is
> actually how I'm doing things now, and I was really interested in switching
> to bc to escape this. Moreso, all of my sites are exactly the same, only
> thing that changes is the information and graphical configuration, which is
> DRASTICALLY different, i.e. - if one user logged in and ended up at the
> wrong site, that would be _really_ bad.
> 
> So in a way, physical location and separate db's are helpful for ensuring no
> data gets mixed up. However, as Justin has pointed out, its makes updating
> functions extremely tedious. There is honestly no need for me to have 50
> copies of sessionauth running. Also, if I add a function to my service, I
> would like to plug it into the central engine and let it work itself out
> from there.
> 
> Is there any way that we can pare this thing down to one set of functions,
> then have different folders/modules for the various sites? The progress
> everyone's been making is truly awesome, but this is a big hang up for me I
> gotta say.
> 
> Alby
> 
> 
> ----- Original Message -----
> From: "Justin Farnsworth" <je...@ey...>
> To: "BINARY_CLOUD" <bin...@li...>
> Sent: Friday, September 07, 2001 12:51 PM
> Subject: [binarycloud-dev] BC Serious Concerns, Production Standpoint
> 
> 
>> Guys:
>> 
>> I have been following silently the shifting sands of BC lately
>> without comment, trying to keep up with the developing trends.
>> 
>> This message may be long, and reflects my understanding of the
>> current file layout and housekeeping related to the make system,
>> and in particular, the make site feature.  Please note that
>> my comments are from the standpoint of production, and I may
>> use some "exaggerated" examples.
>> 
>> As a side note, important for me, is that I have committed our
>> firm to do all new site development in binarycloud, considering
>> the state of things as I previously understood the accommodation
>> of the "problem" of supporting multiple sites.  My concerns are
>> obviously from this production standpoint.
>> 
>> My "vision" may be in error, but I previously perceived that there was
>> a kind of common boiler room with the basic machinery of
>> BC, and then sub-trees would be branched off, for example,
>> the ./user directory for modules, libraries or whatever.
>> 
>> If I now understand it correctly, the aspect of "make site"
>> now creates a complete stand-alone BC "system".  I perceive
>> the following problems, and ask for commentary.
>> 
>> 1.  Module commonality - This aspect was one of the most
>> attractive aspects of BC, namely, if a calendar module
>> was developed, it would be accessable from all sites
>> and there would only be one copy.  Thus, if there was
>> some minor bug in the module, or some small enhancement
>> was desired, editing the module IN ONE PLACE would
>> either correct the problem across all sites, or add
>> the enhancement across all sites.  If I understand
>> correctly, now, if this module is in error, the
>> module would have to be corrected and copied to
>> all sites that use it.  Obviously, this is something
>> that is prone to error if you have 100 sites running
>> with the module.
>> 
>> 2.  Of lesser concern, as probably this has been accommodated,
>> but is still is of a concern until I am assured...
>> This is the scenario, say, of a problem in the future
>> that is found in, say, the Entity Manager.  Now, with
>> completly separated site "systems" a CVS has to be run
>> on all site trees to correct the problem of the Entity
>> Manager.  Obviously, this is something that is prone
>> to error, if you have 100 sites running BC.
>> 
>> 3.  User/Site Class Libraries - I am just uncertain if this is still
>> being
>> thought of.  It is more or less the "user's" problem, as
>> I anticipated that certain class libraries useful for
>> several sites would be kept somewhere in the single
>> system tree.  I realize that the PHP search path can
>> be changed to accommodate this in some other standard
>> place (i.e. /usr/share/PHP), but I originally wished
>> to have libraries somewhere in the "single" BC tree.
>> 
>> 4.  Disk space - This is nit-picking (disk space) in this day and age,
>> namely
>> the 600 or whatever files and directories are to be duplicated
>> for each site.  There is even an argument to "isolate" a
>> complete site in one tree as something that can be easily
>> archived.  But, still, imagine that an application is developed
>> that is a "Volks Kart" shopping cart that is marketed to
>> mom-an-pop shops and you set it up for a small amount of
>> money, with BC, and it is a success and you have 1000 in
>> the region.  Yes, yes, this is exaggerated, but sometimes
>> it helps to exaggerate to see the point that I wish to
>> make, namely the loss of the "single system" advantages,
>> bloating of diskspace usage, and maintenance headaches
>> that _may_ result from the single-site = complete system
>> that seemingly is being adopted.
>> 
>> Does anyone else have these concerns?  Am I understanding this
>> correctly?
>> 
>> _justin
>> --
>> Justin Farnsworth - Technical Director
>> Eye Integrated Communications
>> 321 South Evans - Suite 203
>> Greenville, NC 27858 | Tel: (252) 353-0722
>> 
>> _______________________________________________
>> binarycloud-dev mailing list
>> bin...@li...
>> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>