[binarycloud-dev] BC Serious Concerns, Production Standpoint

[Justin F. <je...@ey...>]

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