OK, so Dan's got the acs-kernel datamodel ported over (though we'll be
wanting some overloaded calls to some of the create-this-and-that
routines to simplify porting - hard to tell which to provide until we
dive in, though!) I've got the beast auto-configuring based on your
database du jour, Oracle or Postgres (easily extensible to others, of
course).
So why can't we have this sucker up entirely by midnight? Well, there
are a few things standing in our way...
First - I'm leaving for a quick vacation tomorrow afternoon, and will
return on next Tuesday afternoon. I won't have net access while I'm
gone, but I will have fun (guess which is more important?) I'll get
back to those who are interesting in helping with porting,
documentation, etc tomorrow before I leave so everyone will know who
has offered to help thus far.
Progress will continue in my absence, however. For instance, the
folks at Civilution are going to be taking a hard look at current
released, beta, and alpha aD packages to try to get a handle on what
really works and what really doesn't (you guys might want to play with
the new Ybos jukebox, too). I think this will help us pick which
modules to port first, and which modules to start discussions on
regarding improvements (the content management system, for instance,
needs UI improvements and I think all are aware that the sysadmin UI
does as well).
There are three near-term critical path items I can identify,
which I hope can converge nicely in parallel to some degree:
- Query Dispatcher
The auto-configurating bootstrap installer (phew!) dies quickly on a
call to an Oracle package (if you're doing this under PG). Rather
than kludge our way around this we need a prototype-quality version of
the query processor.
Ben owns this and Ben has been working on it.
- ArsDigita Package Manager (APM)
acs-kernel is hardwired
into the boot process, but other core packages are driven by the
package manager (as they should be). The package manager needs to let
the user configure packages to support various RDBMS engines, or needs
to figure it out from the locations that datamodels occupy (probably
both, i.e. the second as a default overridable by the package creator).
After that's set up, loading package datamodels for a particular RDBMS
engine will be done just as is done now for the hard-wired acs-kernel
package. The difference is that the APM will figure things out from
XML while acs-kernel is, as I mentioned above, rather
hard-wired.
Also queries need to be "PG-ized" and split out using
the query dispatcher before the APM can do its job. This doesn't look
like a very big problem, though.
I own the APM changes as the necessary changes are an extension of
what I've done to implement auto-configuration thus far. I'll work on
this while I'm on vacation, it will be fun.
- Core data models
When the above two tasks are done
we'll be able to load data models for workflow, the content
repository, etc in an auto-configurable manner.
However, none will
exist for Postgres.
We could use some help here, probably from one
or two folks other than Dan, Ben or me (Roberto's interested in
helping ASAP I know). There just isn't enough work to spread around
widely for these pieces...
We'll try to figure out who owns what here soon - if y'all figure
it out while I'm incommunicado I'd be thrilled.
In addition, over the next week or two it would be fantastic if we
could figure out who will be working on porting which non-core
modules. We've had one person (at least) offer to help on
documentation and a couple to help with Oracle as well as PG testing,
so I'm hoping we can also start revamping documentation as we move
along, keeping it reasonably up to date, in particular installation
docs.
I'd hope that none of us are too proud to work on docs and
testing, but the bitter reality is that we're all doing this in our
spare time, and we do have (and will pick up more) volunteers to help
with these tasks who also don't feel like they're up to speed on
helping directly with the port.
Documentation is as important as the
code, and we've all dealt with poorly-tested aD code in the past so
I'm sure we all know just how important testing is. Those who don't
have the time or skills to dive in and help port but are willing to
help with docs and testing shouldn't worry about respect - you'll get
it, in spades. We'll make you blush with embarrassment.
That's it 'til tomorrow...
