Re: [binarycloud-general] BC quick-start guide?

[James M. <foo...@ho...>]

> > Okay after rooting through things I've got it all working although the
> > install process is a bit buggy. Im running against the current CVS BTW.
>
>Can you define "a bit buggy?" - assuming you do a make it should be happy.

Well, the BC_PATH and BUILD_PATH that live in build/en/htdocs/prepend.php 
were set to /u02/home/odysseas/r2/binarycloud after running make even though 
I had $BCHOME set. Once I set them by hand things worked okay. Also having 
the php short tag '<?' turned off causes pretty much everything to break but 
thats not really a bug I guess.

> >> What's "missing":
> >>     -A second generation authentication system. If you _really_ need 
>one,
> >> you could probably get R1 Auth/Perm (which are quite effective, and
> >> production tested - but 'simple') working with R2.
> >
> > Are you suggesting I use R1 or just cut out that piece and graft it to 
>R2?
>
>The latter, though I would encourage you to wait just a little, because the
>new auth/perm stuff is a hell of a lot more advanced.
>
>But, note that Auth.php and Perm.php are "classified" already from R1, so
>you could probably get them running pretty fast.

But if I do go down that path I run the risk of having to retool everything 
down road anyway right?

> > Also, Im wondering if we need the fine grain abstraction that BC 
>provides.
> > We need some of BC's services but Im concerned that the overhead of the 
>page
> > abstraction is going to be too high to develop our pages rapidly.
>
>I've built huge applications with it, and it speeds everything up. Because
>you need to be organized about using modules, nothing gets "lost" in
>include-land.

What's the nature of the applications that are being built with BC? The site 
Im working on will be used to manage some *very* large catalogs of data. 
Interface-wise there won't be much to it in the beginning.

>
>I'm working on something that will simplify page authoring for those that
>don't need tight control over load order, etc. But authoring pages in XML
>will be really easy anyway :)

But doesn't that work against me if Im relying on another person who only 
groks html to do the page layouts?

That's another question I have. When does the conversion from xml to php 
take place? When I run make? Will I have to 'remake' my whole site when I 
change just one xml file?

>
>Also, remember: the system is a set of tools, the only "requirements"
>really are associated with Module method naming.

Which is really what we need.

>
>One of the things I will do later is build a series of "variant" pages and
>applications to give users a feel for the flexibility of the system. Other
>things first, though :)

This would make things much clearer and lower the learning curve quite a 
bit.

>I lead two projects of similar size, one with bc and one without. The
>project without bc was much harder to deal with because I didn't have a 
>good
>mechanism for controlling the condebase my contractors were generating. The
>second project, with binarycloud r1, took ~half the time to complete, with
>much higher quality code when the project was done.

Did the problems arise because the first team was having to implement alot 
of features already present in R1? Given that, I would expect the code from 
team 2 to be better because the could spend more time on the core instead of 
the support services. But that is just what you said :)

>I haven't done a production cycle with R2, but I can tell you that many of
>the ideas in R1 have been refined based on experiences with the system, and
>it will save you time if you're willing to be disciplined (i.e. maintaining
>coding standards, phpDoc, etc etc.)

I've already documented my classes using PHPDoc. After having been immersed 
in JavaDoc I understand the power of systems like it.

>The page render pipeline in r2 is quite mature and powerful, building
>modules is fast and efficient (and obviously serves to break up your
>application into useable, easily debuggable components)

This is an approach Ive already started using so migrating my current code 
to BC won't be terribly painful. But once I start down that path I don't 
want to have to revert so it's that first leap of faith that Im having 
trouble with at the moment.

>However, as you have pointed out, r2 isn't done. Though simple, the r1
>auth/perm system is quite robust, I'm using it in production now. You could
>probably get them working in a day.

So hypothetically if I decide to just go with R1 and wait for R2 to bake a 
little longer what's the migration path? Should I even bother? Pros and 
Cons?

>
>The remaining tasks are related to EntityManager and the make system:

I happen to have written an EntityManager class for my stuff. This will 
cause problems no?

James

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp