Forum OpenACS Development: What's on the critical path?
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.
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...
CMSI think the CMS will be the killer app for OpenACS. That said, as it exists now it is almost unusable by a programmer and good luck with end users (I have tried).
I really think that a straight port of ACS Classic may be the wrong thing to do. For one, I hope that i18n support is built-in and not an afterthought.
Here is a list of some other things I think should be looked at:
- Templates - fairly complete but still a burden. This may be alleviated if a page builder or something similar gets written.
- Email for login - I know that I am not the only one who has had requests for not using email as a means of identifying a member. In fact most sites I surveyed don't require email and instead use a handle or username. This is fixable in Classic but a major pain if you want to upgrade. It is actually more legacy cruff leftover from long ago
- Hardcoded values - My personal pet peeve is seeing reference data or lookups that have hardcoded (either by pl/sql or tcl) values. It is lazy programming at its worst. I can't think of many cases (booleans, y/n, etc, and even y/n could turn to maybe!) where a simple table lookup wouldn't be infinitly more flexible.
As I attempt to use CMS more, I really think it would be better to redesign the whole thing and do it right. It is not sub-site aware which is a major problem.
Also, we should make sure that all the bugs reported in SDM on arsigita.com should be fixed. There are many with patches already submitted but never applied.
Oh migosh, I haven't played with the integrated version, just the
older standalone version, and assumed that this would've been part of
We probably need a side discussion on CMS in general, since it is near
the top or at the top of nearly everyone's priority list.
CMSI could be wrong, but just mounting it up in a different location didn't work. You still only have one instance.
I didn't really want to look at the code yet so...
released so we can consider completing such things ourselves. I don't
know what the story is on the intranet module at the moment, though.
pieces available, but I have no idea how complete they are ...
I will attempt to liberate code, if I can find it. Thanks.
not these are all the existing pieces or not.
version-control4.0d is needed by filemanager4.0a but isn't available
for download. It would be nice to get that made available...
TemplatesI like the templates (mostly) and would like to have all the functionality working. Mainly date_widgets don't work correctly, and wizards and some other widgets don't work. Also, the optional flag needs it opposite, (i.e. if there is no optional flag it is mandatory)
I also would like to modify the form handler (if it is even possible) to get rid of all the hard coded html and make it easier for a designer to use. Preferably by allowing EVERY page on the site to be edited from the browser.
Most designers don't want to learn to ssh into a box and fool around trying to find where in the tree the page is. This got much worse in 4.x because of the request processor. Now people have to understand file hierarchies, directory layouts, modules and etc. to modify a page, and many things like errors still have hardcoded html in the various parts. This makes it difficult to apply skins or even change parts for sub-sites.
I think you're right about the other issues, too. Certainly designers don't want to deal with logging into Linux, etc. We'll just port straight-up first, because templates are necessary for almost everything within the system.
We need to get the SDM set up so we can start tracking feature requests. Talking about features here is fine but a pointer in the SDM attached to the specific module will help ensure ideas don't get lost. Coupled with Roberto's maintenance of a TODO list we should be in pretty good shape for now at least.
As for the TODO list, I'll hack something together today and post a link for review. I'll try to make it an add-on to the SDM so we can be consistent.
their used by every application package in the acs4. i've skimmed
through the code and it looks as though it should be a near drop in
for functionality. the db dependencies seem to be nonexistent except
for api calls to the db.
i'd like to clean up some of the redundancy between the templating
system and the db_api. there are still some artifacts in the
templating system reflecting its design to be a standalone system.
keven scaldeferi put up a nice overview of the request processor and
templating in a wimpy point presentation. the last page goes through
the workings of the templating machinery although it leaves out the
compilation to a proc (which can be inferred from the code::
I just need to integrate Ben's preliminary query processor with my minor APM changes to handle multi-db aware modules and we'll be ready to start rolling. Dan's got the content repository ported, at least far enough to have checked in files (not sure how much testing etc has been done).
I kind of hate to jump the gun like this on other folks but you're right, templating need to be done right off the bat.
Yes, the db_api redundancy needs to be stripped out and the quicker the better. If we wait it will likely continue to linger in the code base.
definitely use it! Ah! Found SDM in my install...excellent!! (If it's
not in the doc subdir, I probably don't see it...*grin*). How soon
'til we can create modules in SDM?
If you're subscribed to this thread (http://www.arsdigita.com/bboard/q-and-a-fetch-msg.tcl?msg%5fid=000Yu3), you've already read seen this. Otherwise, I hope it's helpful. Thanks again for all your patience regarding the intranet package.
We were trying to figure out what the best path would be for the intranet here at ArsDigita. We decided to abort further development on the Intranet package for ACS 4 TCL in favor of speeding up the development time to release core support for Intranet functionality in
ACS Java 4. The overall idea is to port the ACS Core enhancements made in ACS 4 TCL to ACS 4 Java and to complete the ACS Core work that will make it easy to develop an Intranet that is customized to the particular site needs.
Note that almost all the work done on the intranet through early march is available in ACS 4.2 TCL.
More details will follow, but as of now, there will be no release of an Intranet package for ACS 4, TCL or Java. Instead, ACS 4 Java will be enhanced to make it easier to develop an intranet package should somebody be interested in doing so.
In the meantime, we've made available a pre-alpha version of an offices package that demonstrates how the pieces fit together - from using the groups system to model offices to using portals to display information about the offices. This package is very rough and has known bugs, but we hope it will be of use in terms of seeing what type of intranet functionality is provided inside ACS 4.2 TCL. More information on the offices application and how to install it can be found at:
i'll work on the templating.