Re: [binarycloud-dev] BC File Layout, Production Environment

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

> We have taken our cajones in our hands and lept for BC for
> our future production.  It is scary, but so far so good.
>
> I have some issues.  This is nothing "serious" in a
> technical sense, but I have to enter the subjective realm
> here to give you our comments and experience so far.  This
> experience, and our requirements, which _may_ be typical
> for users of BC, may have some influence on you with
> respect to the next CVS.
>
> I will explain.  Let us say that we are a smaller web
> site developer, with, say, 40 sites.  Although this
> may be inaccurate, it _seems_ to us that you are in
> the mind set that BC is, more or less, for one site.

Sort of. (and let me explain that):

core and all of the utilities, libraries, etc aren't something that needs to
be put in with each installation. I haven't put in any work to think about
how to elegantly handle a central binarycloud core "repository" of files,
but to be honest it would be pretty trivial, whatever I decide.

As long as those files are accessible to the system, there's no reason you
can't run (x) sites on the same server with the same core files.

> So, if I use BC for 40 sites, I must do things like:
>
> 1.  under $BC/user/mod, establish a directory for
> each site such as
> a) acmecorp
> b) xyxcorp
> c) the other 38

I think that would probaby get annoying.

If I were doing that, I'd have 40 separate binarycloud/user/ directories,
one user install per site. Easier to configure, easier to test, and easier
to manage in general.

And there's no reason you can't do that and/or the "single monolithic
package" install, which is what I need for web farm installs + updates.

> to put the unique modules for that site
> 2.  under $BC/user/tmpl/html/masters, establish a
> directory for each site such as
> a) acmecorp
> b) xyzcorp
> c) the other 38
> 3.  under $BC/user/tmpl/html/layouts/, establish a
> directory for each site such as
> a) acmecorp
> b) xyzcorp
> c) the other 38

Again, for 2 or 3 sites, I think that would be fine, 40 and you probably
want to consider separating the installs.

> Now, so far, so good, except there is a hell of a
> lot of cd'ing going on during development changing
> from the site-specific DOCUMENT_ROOT, to the site-specific
> modules, to the site-specific layouts, to the site-specific
> masters.

Yeah, and that's a pain in the ass.

> Now, under the modules, yes Virginia, we anticipate to
> have some general things, but, unless I am missing something
> we are not able to "generalize" _all_ modules,
> and certainly not the master templates or layouts with their
> particular decoration.

Correcto

> This is OK.  We get by our wanderings around in the directory
> tree by sourcing site-specific cd-able variables into bash
> to make life easier.

erg.

> I only wonder, and I have certainly not thought this out like
> you have, to do something like have a "site" directory under
> (I donno, $BC/user???) where a small sub-tree exists that has
> the three things which will be in, er, constant edit, namely
> a) modules
> b) masters
> c) layouts

You can consider /user that "site" directory.
You would have no way of knowing this, but I have simplified the user/ tree
to contain fewer directories, as the make system is capable of some of the
build-time organization I want.

You will also be editing queries, and probably config, so again I think it's
quite safe to assume "user/ = site/".

Now, we could allow you to specify the path (and thus the name) of the user/
directory.

So you could have something like:

binarycloud/
    core/
    sites/
        foo_site/
        boo_site/
        moo_site/

in your source tree.

Again, this is probably trivial, but it still would require a little
thought. :)


> NEXT SUBJECT (BUT RELATED TO ABOVE)
> ===================================
> You have implimented what you call "User Constants" in Init.  Well,
> in this you set useful things like DEBUG flags, currency names,
> currency symbols, et cetera.  This is a very good idea.  But,
> what do I do with 40 sites?  What is the meaning of "user" in this
> case.  If I have a German customer, who wants prices in DM, I have
> to pay attention to overriding the so-called "User Constants".
> If I turn on debugging in "User Constants", suddenly all 40
> sites, in production, start displaying funky debugging information.

Again, the argument for separation of your installs. In my last email, I
mentioned config as a problem with having them all squished together.

Point at which you need to maintain different configs, you should have
separate user/ directories.

> WHAT I WOULD LIKE IS another "level" incorporated into binarycloud
> that would be "site specific".  I would like an environment handled
> for the site, called, say, "Site Constants" that Init would handle
> (by including a site-specific file established at a standard place)
> and which would be convenient to override the "User Constants", which
> for my thinking, are kinda only "system default constants".

I wouldn't make that implicitly part of the system, I'd make that an
optional "make structure" - which would effectively allow you to say "I have
three user directories at foo/ moo/ and boo/, please include them in the
make"

I probably wouldn't want to have another "layer" on top of "user" defaults,
is't much simpler to just maintain separate user/ trees for each project and
their corresponding config.

> Yes, yes, I know I can do workarounds by resetting "User Constants"
> in the $Mod->Init() all over the place, or some other artifice.
> But, I don't want to do that.  For a specific example, I certainly
> want to easily turn debugging on FOR ONE SITE ONLY.

Yes, doing it that way is kludgey and the whole point is to avoid
kludgeyness at all costs :)
Separate user/ trees also solves this problem.

> Therefore, my suggestion is include the abstraction, somehow, of
> a "site layer" in BC.  This could be handled in the 'init' array
> with a gizmo like
> 'site' => 'acmecorp'
> that would then let BC know where to look for some of the files
> it needs in, say, sub-directories of standard places, with the
> subdirectory named "acmecorp".

Which is sort of how it would work.
It would almost certainly be a function of our make-prepend, which would set
the site name in each rendered htdocs.

> All I am asking is for you to think about this, think about my
> problem in a production environment.

And this has been brought up by others, whom I am to have a conversation
with today. What you are asking for is both reasonable and "normal" - and I
see no reason not to allow for multiple user/ trees in the same build
context.

> LAST INSIGNIFICANT BITCH
> ========================
> This is completely subjective, but until I went through the
> code, I was derailed for a while by what I consider your
> excellent nomenclature/taxonomy.  I suggest a nomenclature change...
>
> I do not understand why you call "load_order" by that name,
> since is seems intuitive for me, it should be called
> "init_order" in the $bc_page structure.  For me, it has

That is a very good point. Note that Page has been rewritten (it's tiny,
now) - and I'll change that. Excellent point.

> nothing to do with "loading", but represents the order of
> "initializing" (very clever, BTW).  For a while I though
> this was a control that ordered the module DATA collection
> as the page content was built up from modules.  I thought,
> geez, great, if I wish to change the module content order,
> I change the load order instead of moving the arrays around
> in the $bc_page hash.

yep!
but, it is _VERY_ important to note that there is no "print" order: we
assume (I think reasonably so) that you want the modules printed in the
order they were specified, assuming you are not using a module layout.

> I also would not mind having modules being accessable by name
> in the layouts (am I driving you crazy yet?) instead of doing
> things like:
>
> <?php echo $Page->output['content'][1]; ?>
> HTML DECORATION HERE
> <?php echo $Page->output['content'][7]; ?>
> HTML DECORATION HERE

Agreed, and I believe this will happen.

> because I have to make sure I align the $bc_page hash
> with the layout by the order of the module in the hash.
> I would rather only have to remember the name of the
> piece that I had to put in the layout, viz:
>
> <?php echo $Page->output['content']['julie_bio']; ?>
> HTML DECORATION HERE
> <?php echo $Page->output['content']['julie_nude_pics']; ?>

there is a problem with that:
you can have the same module printed on the same page as many times as you
want.
actually, the current r2 test page does just that.

$Page->output['content']['module'];
is meaningless in that context, which _one_ should I output?

becuase you can pass in options, each of these modules with the same name
could out put vastly different markup.

another way to support that is to make you explicitly "name" each module in
a page definition array.

I did that for a while, and it annoyed me. So I killed it.

Part of the revisions of Page a bit later will include an abstraction of all
that stuff which will use an external class to do template application.

> I don't know if a "parallel" named hash could be built up
> in Page with these named keys in addition to the simple
> index array.  Making two arrays for the content is
> perhaps an expensive solution (although BC is not necessarily
> designed to be fleet-of-foot).

Doing a paralell thing would not work, because the class instances of the
modules is actually stored within $Page->modules.

and BC _is_ designed to be as fast as is possible given the services it
provides. I strive for .1-.4/second per page render.

> That is all for now.  Don't let this scolding discourage
> you, the child is still very much loved.

No bad news so far... :)

_a