Forum OpenACS Q&A: PostgreSQL driver

Lately there have been a flurry of AOLserver modules committed to the
AOLserver CVS: ns_imapc (imap client), ns_snmp, ns_cache got adopted,
ns_xml 1.5 released, ns_encrypt (strong encryption, horray!), ns_image
(for identifying image).

This is all great news, but even better news is that Scott Goodwin
seems to have become the (un)official community liason wrt the
AOLserver tree. He is importing these modules into the AOLserver CVS,
and giving commit rights to their maintainers.

He is explicitely asking for us (OpenACS) to move the latest
PostgreSQL driver to the tree, and he will give the maintainer commit
right to that module.

"The biggest problem is: will the OpenACS crew let me take the OpenACS

postgres module, refactor it and then use that refactored copy,

maintaining it at SourceForge? I realize OpenACS has a terrific SDM,

but I think the AOLserver C modules should be maintained and

distributed from a central location, and that would be SourceForge. If

the OpenACS folks continue with their version of postgres.so, that's

fine, but I hate to see two separate modules whose only real

differences may be cosmetic."

I for one, would prefer if we could just tell people "Go to
AOLserver.com and you can grab everything you need AOLserver-wise", as
long as we have commit privs to the PostgreSQL driver.

What do others think? Who would be the maintainer (one with commit privs)?

But it makes sense to have the driver and other modules hosted in one place, and if AOLserver is to be hosted on Sourceforge, so be it.

Who is maintaining the Oracle driver?

Scott ... thanks for your hard work and it's good to see these useful modules such as ns_imapc get into the official tree.

And, credit where credit is due, most of the ad patches were
from Rob Mayoff.

:)

I'm finishing up some of my modules as well, so I'm kind of interested in this subject.

I've seen how Tcl handled this. It is quite logical. So why can't we just set up an AOLserver foundry? Then I would create a project and just have it added to the foundry. The same with the rest. After all, there may be more and more modules/scripts/stuff with time, so things could get a little messy with just mailing Scottg on setting up a branch in the AOLserver project.

I think there was also a fix from scorecard (getactive now I guess)
which should be pulled in.  I am not sure who to ping there though.

Good idea, but not sure we need to do that yet.

I wasn't suggesting we make a branch on the real AOLserver core tree, but instead import an entirely new copy of aolserver-aD and aolserver-win32 as totally separate modules within the top-level AOLserver SF tree.

That way if anyone messes up with CVS, the damage will be limited to the separate tree and not affect the core.

Also, I'd like to manage user perms and such from one SF project admin interface so the rest of you can focus on working on code.

http://phpsource.net/aolserver/

Please make sure you check this driver out when you start importing stuff into CVS.  I don't care if you use it but just want to make it available.  We've been using it in production for a while now and it seems stable.

In response to Jeremy's posting: the things you said are the reasons why I want to get the modules centralized at SF, particularly your comment about making formatting changes. I want to help refactor and make the modules consistent inside and out. It will be easier to accomplish that if there is one place the code is maintained.

I'll work with you and Jeff Davis to get the initial import of nsora in. You two can discuss what order you'll patch the module to make it current.

I'd like to see each commit tagged in the following way:

I import the initial code and then tag the code with 'start'.

Every release is tagged as:

  v1_0
  v1_1

and so on.

Right after a new release, the major/minor numbers are incremented as needed, and "beta" tacked on the end, like this:

  v1_1       (the release)
  v1_2beta1  (the first beta point)
  v1_2beta2  (the second beta point)
  v1_2beta3  (the third beta point)
  v1_2       (the next release)
  v2_0beta1  (...and you get the picture...)
  v2_0beta2
  v2_0

This keeps the tags short and easier to read on the cvs browse web pages. I realize it's rather arbitrary, but I'd like to standardize on this scheme for all modules.

Would it be possible to create an automated process to take a release of AOLserver core and apply the patches to make it work on Windows? If so, then I'd say get the Win32 port working with AOLserver 3.5.0 / 4.x and package the patches into a distribution that has a makefile to apply them. Every time a new AOLserver release was ready, Win32 maintainers could go and update the patch distribution.

As for the modules, there's no reason a patch file can't be maintained in the module dist and a makefile target added to apply the patch for Windows users. Can we do that for now?

Where can I go look at Yon's test suite framework? I'm already working on one. I hear Jerry Asher has a test framework too that I'm going to look at.

Patches for modules would probably be fine.  I wouldn't be optimistic about an automatic system working with the core; I expect some manual merging will be necessary.

I have oracle 2.3, 2.4, 2.5 and 2.6 all as released from aD. I checked and the copy of 2.6 at Eve's site and the OpenACS tarball both match.

I also have the version from Jeremy Collins which he called 2.6 and was based on the aD v2.5 but there are a lot of cosmetic changes and it is hard to figure out what should be folded in to the next version. The diff from aD 2.5 -> aD 2.6 is very small and easy to add to Jeremy's version but I am not sure how well his version has been tested.

There is also a later version than the 2.6 release which Rob Mayoff had (which hopefully Rob or Andrew will send to me shortly which was ora8.c v 1.60 in the aD CVS).

Also, there was a change that I never put into the released version since it was never clear to me what the right answer was (cf http://ccm.redhat.com/bboard-archive/webdb/000d9f.html )

I think what we should do is put up the 2.3 -> 2.6 sequence, then try to pull in anything else that might have been fixed elsewhere and make that 2.7beta.