talli

talli

The .info file does indeed spec database support as you're assuming in your XML snippet.

The OpenACS core and APM support legacy ACS 4 Classic packages as well as those extended to work with our core.  I just moved a large ACS 4 Classic site to OpenACS 4 as an experiment with no problem.  There are some minor differences in acs-messaging and acs-mail, but I think those could be replaced with their ACS 4 Classic versions if someone didn't want to do the minor hacking necessary to use our slightly modified stuff.

OpenACS 4 incorporates a bunch of bug fixes and some (though not many) important performance enhancements, especially in the area of permissions checking.

So ... in an ideal world you folks at Ybos might explore loading up your custom packages written for ACS 4 Classic on OpenACS 4.  You might find it painless.  Or perhaps very slightly painful.  I doubt it would take someone more than a day or so (given a machine that runs Oracle reasonably fast!).

It would be an interesting experiment.

The reason I mention this is that OpenACS 4 packages running on the ACS 4 core will break (the APM will choke).  So maintaining a repository with application packages from both code bases would confuse someone using ACS 4.

On the other hand, someone running the OpenACS 4 core should be able to download a package and our APM will recognize it as being Oracle-only if it's an ACS 4 Classic package, and Oracle/PG if it is one of our fully-ported OpenACS 4 packages.

I'm rambling but hopefully this makes some sense?

If you've kept track of what those hacks are, it mightn't be much of a problem to make our standard classic stuff play well with your setup.

OpenACS 4 incorporates a bunch of bug fixes and some (though not many) important performance enhancements, especially in the area of permissions checking.

At least some of which we've incorporated into the classic version, but I'd be interested to see what else you guys have cooked up beyond what I've seen on the bboards. I have a few more ideas brewing myself, but I haven't had time to test them all out.

If there's one thing we could probably all use a great answer for it's the permissions checks.

The syntax changes from

db_multirow query query_with_perms {
select o1.object_id, o2.name from acs_objects o1, acs_objects o2
where o1.blah = o2.blah
and acs_permission.permission_p(:user_id,o1.object_id,'read') = 't'
}

db_multirow .. .. {
select o1.object_id, o2.name from acs_objects o1, acs_objects o2
where o1.blah = o2.blah
} {
if {![yb_object_permission_p $object_id "read"]} {
   continue
}

The method also relies on an undocumented feature of the db_multirow proc, which will execute the string after the query, a-la db_foreach.

I did have some success creating procs which return a "collection" of ids, which can then in turn be used like a table.  This is very Oracle-specific, and is only practically useful in certain circumstances, particularly answering the question "who has privilege X on object Y?"

PostgreSQL allows SQL functions to return rowsets with the result being used like a table, too, so the tricks mentioned in regard to returning collections in Oracle should be applicable in PG as well.  I already use this feature in our tree (hierarchical query) code.

We don't consider it a marketing stunt, we've just been doing what's seemed to be best for our customers this year. When we started modifying ACS 4.2 Tcl, the OpenACS people were just starting to think about the architecture. Check some posts I made here over a year ago to see what I mean -- here or here, although the second one seems to have lost some of the posts.

We're totally for OpenACS, and as we have time, we're working to roll our stuff back into the OpenACS. It's not just a clone of the OpenACS functionality, though -- that would be totally useless. We've been working on other areas, usually application and usability areas of the ACS. Because of that it's made some internal sense so far for us to go with what we've had.

As I said, we're totally for the OpenACS! As we have resources, we're working on the integration. If you're not too busy, and if you think what we've done might be helpful to the OpenACS, maybe you'd like to help. All our code is available for download on the developer.ybos.net site.

In any event, in the interim, we want to release what we have. If you like it, great! If not, no problem. But, we hope you like it! We do.

Thanks for the welcome, and the corrections! I didn't mean to communicate that you started from scratch at all, thanks for the clarification. We're currently playing with OACS, and have just released an 8i -> 9i patch which think will also work with OACS, and leave the postgres stuff alone. Titi's Message here