Menu
▾
▴
Re: [binarycloud-dev] Er, am I still complaining???
|
From: Alex B. <en...@tu...> - 2001-06-29 17:13:15
|
> 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.
Yessem :)
> 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
I think much of this is moot, in the sense that I agree that we should
support multiple user/ directories in the make system, but at the moment we
don't.
If you want to do some stuff related to that, I'm happy to incorporate the
code :)
> 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
Exactly. Which is why you should have a separate user/ directory for each
site with a unique name.
> 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".
Yep, samep.
> 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.
You _do_ want all that, because it will all be different.
> 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.
I think that would probably be a nightmare :)
> 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.
That would work. you can also run symlinks in cvsroot, so if you do a commit
on common in one directory, the change is reflected for all directories that
are linked.
> 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.
I think it's just a question of "making make" aware of the fact that a
developer might want to have multiple user/trees.
> 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.
Re: constants, probably not.
But again, I think the best way to do this is to explicitly support it,
rather than hack the system.
> 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
I recommend:
binarycloud/
site_name/
mod/
common/(foo)
tmpl/
html/
masters/
layouts/
site_name/
mod/
common/(foo)
tmpl/
html/
masters/
layouts/
etc.
> 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".
Again, this is all just a metter of supporting the stuff you're talking
about.
The make system you're looking at supports only a single user/ tree. It
isn't that difficult to change the make system and some other code to
accommodate what you need, but in that last cvs snap you are not looking at
the solution :)
_a
--
alex black, ceo
en...@tu...
the turing studio, inc.
http://www.turingstudio.com
vox+510.666.0074
fax+510.666.0093
|
