A couple of quick ideas ...
- Query reuse
How about a simple scoping system? Define a scope for each query - file, package or global. File scope would be what Ben's described thus far. When given a query name, have the dispatcher look for a match first at file scope, then package then global, returning the first match.
This would allow for a high level of reuse while not blindly introducing assumptions about names being unique across packages or the sytsem. The potential for query reuse is a major potential benefit of the query dispatcher approach - let's try to think of ways to make reuse practical.
- proc_doc approach vs. XML
The nice thing about doing this in XML rather is that there would be no further need to translate such procs to Java, by either manual or automated means. ACS/Java works with any environment that supports servelets and all you'd need would be to do the XML parse in that environment and the Java could would be up and running. I think the XML approach is the simplest when we consider the problem of perhaps supporting a Java version of OpenACS 4 as well as a Tcl version.
As many of you know I have no personal interest in this, at the moment, anyway. But others have expressed an interest and we've talked about being a "big tent" project, and in that spirit looking forward and helping others by doing what we can now to simplify any future port of Java ACS4 to the OpenACS world is a good thing.
- Three files?
Some of the .tcl scripts have become exceedingly simple, with so much of the application code now buried in PL/SQL (and PL/pgSQL for OpenACS) and presentation split into template files.
Might it be possible to extend the XML definition of queries slightly and have them define datasources as well as queries, at least in some cases? Some of those .tcl files might disappear altogether if we did so...
