There's also an easy-to-use calendar drawing widget that takes an
ns_set of julian date keys and HTML values, parameters for background
and foreground colors, day headers, etc etc etc.

With a little work you can set up a simple calendar which displays
shared and private calendar dates tailored to the individual user.

I assume that the room reservation system uses the calendar module to
store reservation dates, but haven't looked at the code so could be
wrong.  The calendar module itself does no scheduling or similar work,
it is truly just a simple calendar tool.

If you look into the room reservation system, be warned that OpenACS
doesn't support the 3.4 APM tools.  You'll have to unpackge it to port
it.  This shouldn't be hard.

Of course, our 4.1 version will fully support the APM system.

When the tcl file is sourced at startup, does it load gracefully or are there any errors reported?

OpenACS 3.2 predates the arsDigita Package Manager (apm), so doesn't
have any of the package stuff in it.  You have a couple of options,
rip out the package stuff, or wait until we get the ACS 4 core ported
and rewrite the package as an ACS 4 package.

I realize this isn't a very satisfactory answer, you've caught us at a
point where our initial port is obsolete and our future port only just
about to start (hey, it's Feb 3, and we said we'd start Feb 1, we
gotta get going here).

Will this work in 3.2.x or do I have to implement some plsql function?

Regarding ad_proc, I've not taken a close look at 3.4 so don't know what the private/public function flags do.  I suggest you study the code - it may be taking advantage of namespaces (Tcl 8x) or the like to avoid name collisions.  But I don't know.  Does anyone else, offhand?

(I'm busy with a bunch of stuff at the moment, otherwise I'd be willing to dig into the details myself).

The "begin 1:=func_name(); end;" constructs refer to a PL/SQL function.  You have to rewrite func_name() in PL/pgSQL.  You might see  Roberto's beta "PL/pgSQL for PL/SQL porters" manual, also referenced in the "4.0 design" forum.

After re-writing the function, you simply call it like this:

ns_db 1row $db "select func_name()"

Postgres doesn't require the "from" clause in such cases, i.e. no need  to do a "from dual".  Since you're not interested in the result of the function in this case, you don't need to call set_variables_after_query.

One of my upcoming tasks, for a client, will be to generalize the calendar package so it can track *any* object derived from acs_events, rather than just the calendar object type (the acs_event type has all the time and date information needed to display calendar events).

I also have a copy of the 3.4-based room reservation package mentioned above.

The cool thing to do would be to rewrite the room reservation package to use the standard acs_events data type and massage it in whatever other way is needed to make it work well within the OpenACS 4 framework (expose it to the search package, for instance).  By basing it on the standard OpenACS 4 acs_events data type the reservation could then be easily added to the right calendar (AFTER I make the changes to the calendar package mentioned above, which will happen in the next two weeks).

A lot of people would love to have this.  I've not looked at the code for the room reservation system so don't know how closely tied it is to the old intranet package.  It should be generalized in any case if it is.

If you're interested in working on this, e-mail me privately and we'll  talk things out...

Changes: I improved the interface so that the first screen you see is the table showing you which rooms are free and busy. You click on the time slot you want instead of filling out the form, and it gives you the form with the spot you wanted already filled in.