it conforms to the latest additions to the query dispatcher xml
spec, as referenced on the bboard and the files in cvs.

i rewrote the extractor's parser so its a lot cleaner, faster (cut
running time in 1/3:), and does better assoc of queries->procs.

running it on the acs-packages cvs takes about 4.4s on my laptop,
with no abnormal errors. the errors that were generated were all
from library files that either use namespaces, do db calls outside
of procs, or db calls in ad_proc_register_filter. if people feel
that these types of things should be added in let me know.

theres a good amount of documentation included (including some auto
generated documentation of the apis).

i'm going to work on transforming the package files to html tomorrow
and then i'll start helping out with the port.

if you find any bugs, or have some comments post them here or email
me.

which contains a nice set of html pages for browsing package
information. it includes a set of indexe pages that include packages
sorted by release date, number of dependencies, version number,
number of files, and also a detailed page for each packaged.

just untar and point your browser to the index.html

it would be nice if this could be setup on the web here on the
openacs.org, until a fully dynamic one based on either the apm or
sdm comes out.

because these packages are incompatible with the GPL (which i'm
releasing the tool under), i can't bundle them with it.

i've made a tarball of the DocumentTemplate and DateTime packages
which are at the download location listed above.

PyXML can be gotten from pyxml.sourceforge.net

i'm done adding new features to the tools for a little while, only
bug fixes and customization of the current features.

so now i'm going to start working on the port, starting with
templating, and then porting over the datamodel for ecommerce4 and
workflow. i'm primarily focused on the sql models for package
porting so if anyone wants to work with me on the tcl, let me know
(esp. the ecommerce4 package which is incomplete).

btw. i'm being paid to work on the openacs4 port for now, so if
anyone needs some help with something let me know.

its already packaged so you don't need the support libs unless you
specifically use features that require it. which are namely the
package info html generator or the extractor WITH html generation. the
default extractor with xml generation does NOT require the support libs.

i accidently left enabled the html generation in the default
configuration for the extractor which requires the document templates.
turning this off in the config (by commenting it out) will remove the
need for the document templates.

as far as what to work on, its quickly becoming apparent that we need
a package by package break down of who is doing what, and we need it
soon. exchange by private email and geographically restricted meetings
is not cutting it, we need this info publicly available on the web. so
two of the three packages i stated above seem to have prior
commitments, thats fine by me. but this info should be known so work
isn't duplicated and effort wasted.

i'm installing the openacs4 at the moment, and i'm planning on writing
up an install guide based on my experiences.

Kapil ... I just started talking to folks about package assignments via e-mail about five or six hours ago. I don't think it's terribly fruitful to post every question I put to an individual here on the bboard. Group discussions - yes. Individual posts - that's way too much detail. Dan informed me sometime yesterday or early this AM that he was going to start in on acs-workflow, because the content repository has a dependency on it.

Jon Griffin is going to look into acs-notification. He and I exchanged e-mails just a few hours ago (see above).

So ... give folks a chance to get back to me before you demand that I summarize everyone's answers in public, OK? It's hard to summarize responses that have yet to hit my e-mail inbox.

For the record,
you didn't answer my question as to whether or not you wanted to work on templating for FIVE DAYS (I posted it on April 3rd). The fact that I turned elsewhere FIVE DAYS after asking you in public and getting no response either in public or via private e-mail isn't really an indication that I'm plotting in secret to assign packages to others behind your back or whatever.

As soon as we figure out exactly how we're going to structure the tree and how we'll decide who can commit where I will work on getting a list of who is doing exactly what and on which package.

I can't move forward on this sub-issue until I hear from Ben, and he's incommunicado this weekend. I'm sure he'll get back to me on Monday and we'll get things figured out and published by Wednesday. The machine belongs to his company so questions about access are by nature going to be his to make, not the group.

Cut us a little slack, Kapil. I wasn't going to mention that it took you FIVE DAYS to get back to me on my question about templating, but if you're going to slap me around in public I'm going to slap back!

As I mentioned in my e-mail to you regarding the query extractor, it looks like a great starting point but there are some additional things that could be done that would make it even better. The extractor's a great idea, I really appreciate your doing it, and when improved it is going to remove a tremendous amount of tedious work from our plate.

This is where you can really help us the most at the moment. At the moment Ben (or I if he doesn't have time tomorrow) need to modify the query dispatcher to allow the rdbms to be spec'd in the queryset as a default, and the extractor needs to build them that way. As I mentioned, you don't need to build the list of bindvars unless -bind is used, and querytype is no longer needed.

<blockquote><i>so now i'm going to start working on the port, starting with templating, and then porting over the datamodel for ecommerce4 and workflow. i'm
primarily focused on the sql models for package porting so if anyone wants to work with me on the tcl, let me know</i></blockquote>
At the risk of sounding more irked than I am...
<p>Look, folks, anarchy isn't going to cut it.
<p>Kapil, complaining that I'm not properly telling folks who is working on what while suggesting folks e-mail YOU rather than ME if they want to work on ecommerce isn't very productive.
<p>If you want me to do a better job organizing this project, don't make my job harder by suggesting folks circumvent me. In seems rather unfair that you slap me because you don't feel the process is open enough while simultaneously working to make that job harder for me.
<p>Likewise, don't just simply announce "I'm going to work on workflow" without checking with me first. If you'd checked with me I would've told you that Dan was working on it. For the record, Dan checked with me first to make sure that no one else had picked it up, just as he did for the acs-content-repository.
<p>No one else is picking up ecommerce4 at this point, so you're more than welcome to it, and I'll put you down for it.

If it was needed by the query dispatcher, it would've been included.
IGNORE THEM.

(I've e-mailed more details to Kapil, but the spec didn't suggest we needed support for them in the query dispatcher, and the spec was reviewed by Dan Wickstrom and I, who both worked on the bindvar parts of the driver, i.e. we would know if support was needed so our silence wasn't entirely out of ignorance...)

You have to be *really* careful, though, because parameters used out-of-order in the Oracle version which don't cause the type signature to change will cause subtle and very hard to debug errors to creep into the code.

So ... tricks of this code should be combined with a *very* careful read of each call to make sure the parameter order is correct.