binarycloud-dev

[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

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

[binarycloud-dev] how close are we to a stable environment?

[Seth B. <se...@su...>]

What do you guys suspect the ETA is to begin developing against a stable
binarycloud2 system?

//.s

Re: [binarycloud-dev] how close are we to a stable environment?

[alex b. <en...@tu...>]

> What do you guys suspect the ETA is to begin developing against a stable
> binarycloud2 system?

Depends on what you need to do: the page render pipeline works fine, but
EntityManager, etc aren't done.

The ETA of EntityManager and is associated infrastructure (along with the
other make-related stuff that needs to happen) depends entirely on how many
people are contributing code, and how much time I have based on what
projects my company is doing.

I'd guess 2 months, but that's a guess. Coule be a lot faster or slower than
that.

_a

> //.s

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
>

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
> 

Re: [binarycloud-dev] Yee haw

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

I saw that, its awesome. This make config whizz-bang you speak of sounds
rad.


----- Original Message -----
From: "Alex Black" <en...@tu...>
To: "binarycloud-dev" <bin...@li...>
Sent: Friday, September 07, 2001 2:28 PM
Subject: Re: [binarycloud-dev] BC Serious Concerns, Production Standpoint


> 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
> >
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>