Thread: [binarycloud-dev] Er, am I still complaining???

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Alex:

I have downloaded the latest r2 tarball with the "make system"
embedded, the slimmed-down Page, and the change in module
structure by making X->Init() into a constructor.

Now, I don't yet have my arms around this new thingy, but
I must express my happiness with make(1) being used, because
I can add my own targets for "administrative" matters.  FYI,
I love make, and probably have 30 targets in  typical
makefiles for our site(s) administration.

Still, and I don't claim that you intended to solve my
administrative problems with BC.  But, I think that this
email will be useful, again, to show what we, a small
developer with about 40 sites, are up against.
I suppose that there is a philosophical clash, as, to
me, BC is designed with a mindset of it being for
"one site", while youse guys say, "No, you make different
sites with different modules" or some such.

There is a wider context, and here it is.  The file layout
for us, is:

--HTTPD_ROOT--	+
		|-site_name0-
		|-site_name1-
		|-site_name2-

and so on, for each site, and with virtual servers pointing
to site_nameN

and for binarycloud:

/usr/local/binarycloud/-+
			|-user--|-mod---|-site_name-
				|
				|-tmpl--|-html--|-masters
						|-layouts

With this structure I have some issues:
1.  For the site-specific modules, it is OK because
	I can avoid name clashes with a subdirectory
	that is "accommodated" in BC.
2.  For the masters, I feel cheated, because I have
	to add another subdirectory for each site.
	I am going to have, at least, one "main.tmpl"
	for each site.  I DON'T WANT to name my
	templates main.acmecorp.tmpl, main.foobiz.tmpl
3.  For the layouts, the same problems exist as for
	the masters.  We are going to have a _lot_ of
	layouts (our company is run by artists) and
	to avoid name clashes, I don't want to have
	to have
		page1.acmecorp.layout
		page7.xyxbiz.layout
		page3.foocompany.layout
	in one directory, ergo the subdir "necessity".
4.  For the server root, it is as above, and there
	is "no problem"
5.  Now for any site, with BC, there are at least
	two trees (minimum) to deal with for those
	administrative matters such as backing up,
	archiving, and using CVS.  The minimum
	would be the HTTPD_ROOT/site_name and
	er, what the whole bloody BC user subtree.
6.  How do I work at home, or even at work, with
	CVS, for example.  With the present file
	layout, I have to have a module rooted at
	the webserver subdirectory site_name, this
	is OK.  But where do I CVS to work on
	site-specific modules, or site-specific
	layouts, or site-specific templates?
	Do I have to bring over the whole bloody
	sub-tree starting at BC_PATH/user?  I
	don't want all that.
7.  To solve the name clash problem, if I put site_name
	subdirectories under masters and layouts,
	I now have three sub-tree "units" for each
	site.  Sure, I can consider these three
	sub-trees as a "site" in my backup planning,
	my CVS planning, my development server to
	production planning.
8.  BUT, some sites will use the "common modules"
	that we wish to develop.  So, what do we
	do, I suppose establish a ./common subdir
	under ./user/mod, and make this a "node"
	for our administration needs.  That way,
	I could CVS this sub-tree, backup this
	subtree, copy to production this subtree
	et cetera.

I donno, I don't have a plan yet.  I may have to do
some silliness with establishing symbolic links to
reduce the complexity of administration, or something
else.

Can I take risks like overriding things like
BC_PATH_USER or BC_PATH_MOD.  I don't even want to
go there, because you may break me in a future
release.

I don't know if I am explaining my problems well.  Be
gentle, and try to understand that I want things
to be easy to administrate, it is a huge, flippin'
headache in everyday life.  So, although I have not
thought this out well, it seems that a way to
reduce my problems would be

-/binarycloud/--+
                |-user--|-the_common_stuff_here
		|
                |-site1-|-mod---
                |       |       
                        |-tmpl--|-html--|-masters
                                        |-layouts
                |-site2-|-mod---
                |       |
                        |-tmpl--|-html--|-masters
                                        |-layouts
                |-site3-|-mod---
                |       |
                        |-tmpl--|-html--|-masters
                                        |-layouts

Now,  I only have 2 trees to deal with for a site (unless I
want to work on the common_stuff, I can work at
home and checkout things like:
	site1-bc (site1 tree above)
	site1-docroot (site1 in the server DOC_ROOT)
	bcuser (the common stuff)
	site23-bc
	site19-docroot

or archive these, or delete these, or move these.
The above would require some ability of overiding
system_constants, or integrate some true
user (as in client, not BC user) definitions.
Right now, in any index.php for defining a layout
file, or a template file, I can't get above the
html directory.  For modules, I cannot get above
./user/mod.

This is not whining.  My estimation for BC remains
high.  It just seems like the anticipated great
payoff of using BC is somehow diminished by a
greater administrative load, besides the necessity
to cd a lot because relative cd'ing is "broken".

Regards,

-- 
Justin Farnsworth - Technical Director
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722