Forum OpenACS Development: Response to BBoard development

Yes, Bryan's philosophy matches my own very closely.  Let's get Humpty  Dumpty back together and sitting on the wall first and decide on whether we want an omelette or souffle later.  Otherwise he might rot before we make up our minds.

I feel especially strongly about this because porting to the OpenACS 4.x structure, including porting queries to Postgres, isn't that difficult.  At the same time it's rather tedious and we need to settle  in, and get that tedious work behind us.  Distractions are risky.

There are some things we *have* to redesign and rewrite, i.e. Oracle Java-dependent SMTP handling and the like.  With these things on our plate along with porting, we've got plenty of work to do for round one.

And, believe me, this is just round one.  Don't get too caught up on the need to make everything absolutely perfect right off the bat.  A bunch of us are in this for the long haul.

I do want to encourage continued discussions of this sort, though, as long as we actually make progress porting existing code in parallel.

The whole bboard issue is one which many people care about, and none of the existing aD solutions are perfect.  But we can get them up in a hurry.  Remember, the first bboard port to PG took me 10 hours spread over a Saturday and Sunday.  We can afford to throw a port of the existing 4.0 bboard away later if we decide it sucks so bad that we really need to do so.  We won't have that much effort invested in the port.

And of course there's no reason there has to be a single bboard package.  There can be more than one, which users can choose.  One advantage of using the Content Repository is that other pieces of OpenACS can plug into the content no matter what bboard package is being used.  Keep this in mind when you consider dumping the CR...different bboard packages become different skins over content.

I need to add more documentation to my little wimpypoint presentation, to make sure that people do take notes and them as features and bugs in the SDM entry for the package they're working on.

And absolute horror stories need to be fixed.  I'm doing a bit of that with the APM, which needed work anyway in order to add multiple-db support to packages in a visible way.  We've seen some progress on the  permissions front.  In the case of datamodel problems we want to work  with aD whenever this is possible.

As far as specifics I'll only comment on Henry's comment about the sort key used by Philip in the original bboard code.  It is indeed a good way to track things and is a standard way of implementing hierarchies in the SQL world.  I work with a taxonomy of North American birds that uses a very similar technique, though it is slightly more rigid, since the taxonomy's known in advance.  It works very well, as does the original bboard scheme.

Not only is CONNECT BY not portable, but it tends to lose its seductive charm as you try to do ever-increasingly complex things with it.  Datamodels that depend on CONNECT BY queries seem somewhat fragile to me.