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

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

> 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.

That's essentially correct. Though we'll need to build in a little path-fu
for the make system that will allow us to easily switch between
language-build versions of the binarycloud core classes.

I.e. if you're sharing the bc-core classes, you need to be able to easily
switch from en/binarycloud to fr/binarycloud in that central store.

> 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.

That's correct.

> 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.

No, it isn't.

You would modify your original files in default/ or common/ or whatever you
want to call it, and run make again, which would propagate your change to
all of your individual site installs.

That's the purpose of the make system - i.e. to maintain a single tree of
source, and then build different flavors of that source tree:

Maybe for one server, you need to have your code run through zend encoder.
Maybe for another, you want to have a 'complete package' (i.e. all
binarycloud code) for each site
Maybe for another you wan to share a single repository because you're
hosting 50 sub-sites, etc.

> 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.

Not 100 sites, 100 _servers_.

But that has nothing to do with binarycloud: if you are managing a
homogenous codeset across a number of machines, and make a change to the
code in your central repository, of course you will have to propagate that
change throughout your cluster.

If you are running a single machine with many sites, you'll be able to set
it up so you share all bc core classes, so you'd only have to sync 1 file.

> 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.

That will be supported.

I discussed this a while ago, i.e. the idea of a 'default' site tree which
will be compared to each site tree as it is being made - for files that are
missing in the current site, but present in the default site, we'll copy
them over and install them as if they were a part of the current site.

That means you can share configuration between 45 of 50 sites, and for the 5
that need special configuration, write a configuration files.

> 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

That won't be the case. With a shared bc-core, you'll only have to copy site
specific files.

of course none of the stuff that I have mentioned above is _done_: if you'd
like to start hacking to make it work, I would welcome your commits.

> 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?     

Not really: you're looking at the _current_ system, not the designs I've put
up on the list.

Everything you originally brought up, with a few modifications is in the
todo. I intend to support as many strange permutations of make config as
possible, but it all depends on who is willing to contribute what.

If you want something in the make system, please check with me first to
compare design notes, but other than that feel free to hack the make system
to add configuration options for whatever kinds of setups you would like.

Everything you mention above is going to be in the roadmap document I'm
almost done with, btw.


best,

_alex