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
>