Forum OpenACS Development: Move openacs4.tcl AOLserver config file to real location
/web/service0/etc. I think this is an excellent convention to recomend and adopt.
The file doesn't have all that much history in CVS, but it'd still
probably be better to copy the
repository file over to the new location.
Comments? Yeahs, nays?
Second, the standard has been to put everything into /files and then move it around later.
Third, I already broke the tradition by creating a subdirectory for all the tutorial files.
Despite that, I think it's simpler to keep as much as possible in a flat directory and put the structure in the instructions.
Secondly, it certainly is not simpler to "put the structure in the instructions" than it is to provide the correct structure in the first place.
Improvements to the AOLserver config file are easier and more likely to me when you can actually run the file as provided. The currently provided config file is good in its simplicity, but is far from an example of best practices. It is quite feasible to greatly improve it while still keeping it simple.
/openacs-4.6.2/packages/acs-core-docs/files in the 4.6.2 final tarball. CVS seems to be down so I can't check that right now.
What I mean by "put the structure in the instructions" is that the files in acs-core-docs/files go into various different places, including but not limited to /etc/ and /web/service/etc. And those places may not be the same on different machines and different flavors of OS. So the text of the instructions currently provides the mapping from the catch-all /files directory to the right place in the final install. Since the new "right way" has been vetted only by a few forum threads, I was hesitant to impose that into the file structure. If there's consensus on new file structure that works in most cases, then I agree we should implement it.
Have a look at the new config.tcl.txt (it seemed to be the convention to tack on a .txt to all the various files - perhaps some of them were accidentally interpreted at some point and the convention has outlasted its need? Should we dump the .txt?) - I would love feedback on how it can be improved. I tweaked it a bit to accomodate nsopenssl, and to increase the number of access logs kept so that people don't lose log files before they get around to realizing they need them and where they are, and to put everything in the /web/service structure.
/etc/openacs.tcl seems logical for a single app on a machine
/etc/openacs/appname.tcl seems logical if you have more than one instance on a machine.
/usr/local/aolserver/nsd.tcl is the default for aolserver
/web/appname/config/nsd.tcl is a common tradition
/data/servers/appname/config/ is also common in my company.
The list goes on, there's no way to please everyone so putting it in /files with instructions and letting people put it where they like makes sense to me. Bottom line is it really doesn't matter where it lives, as long as the path is given as as arg to the nsd binary.
We are neither mandating nor even suggesting putting anything
into /etc/, /usr/, or anywhere else in particular in the user's file
system. What we are discussing, is where to locate the AOLserver
config file in the OpenACS CVS repository. Joel and I seem
to have agreed that
etc/config.tcl or something like that is the best place.
If we do that, what it means for the user, is that when a user checks
out OpenACS from CVS, or downloads and untars the OpenACS release
tarball, he can put it anywhere he wants. But if he, say, untars
/web/mysite/etc/nsd.tcl will already be there, in the
suggested and immediately useable location. There is no reason that
he should have to manually copy the nsd.tcl we give him from some
other random location into
can move thigns around if he wants to. But the new docs are
going to recomend using that location for the AOLesrver config file,
so we might as well actually put it there.
For the vast majority of people who will be happy with the standard OpenACS AOLserver config file and it's standard location, it's much easier and simpler to just have it there ready to go right out of the tarball. That way, those folks automatically get the benefit of OpenACS best practices. And for the minority who want to do it there own way, they can, this change makes absolutely no difference to them. But there's no reason to force people to "roll their own", which is what we're doing now.
My bad, I understand now. What you are suggesting sounds good to me.