Forum OpenACS Development: Re: Multiple DNS and subsites

Posted by Gustaf Neumann on
The right way to aim for a "stable" host-node mapping is to add tests to the regression test suite (after sorting out, what in detail is expected or not). The host-node mapping is (and was since ever) very limited, but it seems useful as it is for several sites.... but actually, i am not aware of site using it.

A much more general virtual hosting approach is available in NaviServer (run multiple servers from a single nsd process, which might or might not have the same blueprints), but that approach is not integrated with OpenACS, since in OpenACS we try to keep AOLserver compatibility.

All releases of OpenACS are tested thoroughly (regression test, OpenACS installation tests, DotLRN, frequently used packages, ...). In addition, is running as close as possible on the HEAD release (currently the newest version of the oacs-5-9 branch), so on the 70 packages in use on, bugs are earlier detected.

If someone finds a bug (in templating, core, ...) please submit a proper bug report, where this issue can be addressed. I am not aware of any changed "ad_conn behavior used to generate forms". Such changes would affect substantially. Vague and nebulous statements are not constructive and do not help.

Posted by Benjamin Brink on
I'm sorry; I should have provided more context for my comments about the unstable nature of ad_conn in context of host-node mapping:

Since Uri is using aolserver 4.5, I mentioned our local experience with using host-node mapping with aolserver 4.5 --not naviserver.

site_node::conn_url was developed (in 2009 and submitted to acs-core) in order to work around the inconsistent behavior of ad_conn. It was meant to provide a consistent url depending on if it is called from a main site or when called from a host-node. However, changes in core dependencies caused it to break soon after also. A fix was again provided that worked locally, but it again broke on next release. iirc. CVS browser highlights some of the history and forum discussion on it.

Part of the issue had to do with inconsistent view of the purposes of some of the underlying code between core developers.

The core and maintenance process has matured significantly since then. I'm sure a re-examination and development of regression tests will stabilize the feature into something quite useful. I'll file a bug/suggestion shortly.


Yes. Regression tests should be added at some point to stabilize feature(s). I was going to re-visit this and provide regression tests with bug report/suggestion; Alas regression tests are a few months away still.