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

[Albert L. <a.l...@ve...>]

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
>