Forum OpenACS Q&A: Ybos ACS (Classic) 4.3 available

Collapse
Posted by Titi Ala'ilima on
I just uploaded Ybos's ACS 4.3 to developer.ybos.net.

Highlights include:

  • permissions improvements (thanks openACS!)
  • enhanced permissions/privilege UI
  • enhanced site-map functionality
  • package wizards, to execute scripts upon creation, mounting, unmounting, or deletion of package instances
  • lots of kernel cleanup
Collapse
Posted by Jade Rubick on
Thanks for making this available. It looks like you've cleaned up a lot from the original ACS version.

Is there any plan to merge the OpenACS and Ybos Classic versions? It would seem to make sense, but I don't know the background behind this.

Collapse
Posted by Titi Ala'ilima on
Ideally, that'd be great.  We'll see how it progresses.  Ybos has had a really busy year, but we have a short window of breathing space to re-organize our code and release it.  While we're relatively free, we should be able to run a few tests with the OpenACS code before we get sucked back into client contracts, and hopefully that will at least bring our paths closer together, in the long run if not sooner.
Collapse
Posted by MaineBob OConnor on

Hi Titi,

The above link returns a not found error.

Can you also provide a brief overview of ACS4.3 including what is needed. Does it only work with Oracle?

-Bob

Collapse
Posted by Titi Ala'ilima on
I copied the post from my post on our site, and forgot to edit. Here's the real link!
Collapse
Posted by Peter Vessenes on
Hi Bob, yes it's Oracle only. Should work with either 8i or 9i, though.
Collapse
Posted by Titi Ala'ilima on
Yes, Bob, this is an Oracle-only version. As a matter of fact, it will only install fully on Oracle 8i Enterprise Edition. If you have Standard Edition, you lose the bitmapped indices and can't rebuild your interMedia index online. You might miss a couple of other random features.

I could pass on a version that's 9i-friendly, but most packages won't work on it without fixing. If you're interested in 9i porting, come over here and let us know.

Collapse
Posted by Don Baccus on
We're interested in 9i, of course ... this forking should merge, we'll just each duplicate effort otherwise.

BTW we decided to drop bitmap indexes and online Intermedia re-indexing by default due to the high price difference between SE and EE.  It turns out that aD folks weren't able to point to any testing to show that the bitmapped indexes on this particular datamodel (ACS 4, in other words) made any significant difference in performance.  Certainly those who've rolled out production sites without them don't seem to have any problem.

Intermedia's more crucial for some sites, of course.

The key is that we've left the bitmapped indexes commented out (and replaced with btrees, of course) so one can put them back in if they're buying EE.  Ditto InterMedia.  If they can afford EE they can afford to ask here for free advice on how to reenable these features.  :)

Nothing else from EE is used as far as anyone has found, AFAIK.

Collapse
Posted by Daryl Biberdorf on
Just to clarify, Don, what's the issue with interMedia in SE?
Collapse
10: 9i-friendly version (response to 1)
Posted by Titi Ala'ilima on
I put up the 9i-friendly version here. None of the apms on our site right now will work with it, but we will making all of our future releases 9i-compliant. This has some bearing on the future of merging our Classic with OpenACS, as this means our future work will be incompatible out-of-the-box with OpenACS as it is (mostly because all the "delete" procs are changed to "del"). You might want to consider taking the large, but surprisingly painless step of changing over your plsql code so that it will function with Oracle 9i. We wrote a few scripts in tcl and perl that make it fairly easy, even to do it on a live database. I'm fine tuning some of it and I'll be putting it up on our site soon.
Collapse
Posted by Don Baccus on
What else was necessary other then "delete()->del()"?  We were aware of that one.

Your scripts would be more than welcome.  We decided to put off 9i support until after this release cycle, partially because of resource issues (i.e. available folks) and partially because I didn't feel like pushing it after hearing a variety of rumors about the stability of 9i.  I get the impression that most of us here servicing clients are happy to stick with tried-and-proven 8.1.7 for a few months.

My thinking is that we switch to 9i for our second release cycle.  9i provides SQL92-compliant outer joins, the same syntax PostgreSQL uses, so among other things we can share more queries than has been possible in the past.  And the more queries we can share, the easier it is to support new packages for both RDBMSs.

Collapse
Posted by Titi Ala'ilima on
We changed "rename" to "rename_it" (kinda dumb, but thought "ren" would be more confusing).  All default values have to match between header and bodies of packages, about a dozen of which slipped by unnoticed with 8i.  And the relational constraint checking views rel_constraints_violated_one and rel_constraints_violated_two produce the infamous and dreaded "ORA-03113 end-of-file on communication channel", so we changed them.  I don't know as they ever did us any good before, so we can't tell whether our altered versions are any worse.  There was one call to ctx_doc.filter which was getting confused picking which version to call.  All in all, I think most of the "problems" are actually Oracle 9i being stricter about enforcing things that probably shouldn't have happened in the first place.
Collapse
Posted by Don Baccus on
Yes, in the case of reserved SQL92 keywords this is the case (aD named PL/SQL update procs "edit" rather than "update" because "update" was rejected in 8i, so Oracle is just completing a process that should've been finished earlier).

The headers check is fine, easy to fix and was a bug before, so that's good.

Crashing on a constraint, though, doesn't sound like a bug fix to me :)